#
29441e4f |
| 29-Jan-2025 |
Nikita Popov <npopov@redhat.com> |
[IR] Convert from nocapture to captures(none) (#123181)
This PR removes the old `nocapture` attribute, replacing it with the new
`captures` attribute introduced in #116990. This change is
intended
[IR] Convert from nocapture to captures(none) (#123181)
This PR removes the old `nocapture` attribute, replacing it with the new
`captures` attribute introduced in #116990. This change is
intended to be essentially NFC, replacing existing uses of `nocapture`
with `captures(none)` without adding any new analysis capabilities.
Making use of non-`none` values is left for a followup.
Some notes:
* `nocapture` will be upgraded to `captures(none)` by the bitcode
reader.
* `nocapture` will also be upgraded by the textual IR reader. This is to
make it easier to use old IR files and somewhat reduce the test churn in
this PR.
* Helper APIs like `doesNotCapture()` will check for `captures(none)`.
* MLIR import will convert `captures(none)` into an `llvm.nocapture`
attribute. The representation in the LLVM IR dialect should be updated
separately.
show more ...
|
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
658b260d |
| 22-Dec-2023 |
Nikita Popov <npopov@redhat.com> |
[Attributor] Don't construct pretty GEPs
Bring this in line with other transforms like ArgPromotion/SROA/ SCEVExpander and always produce canonical i8 GEPs.
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1 |
|
#
ae6ad317 |
| 25-Jul-2023 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] Try to remove argmem effects after signature rewrite
If the new signature has only readnone pointers we can remove any argmem effect from the function signature.
|
Revision tags: llvmorg-18-init |
|
#
55544518 |
| 10-Jul-2023 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] Allow IR-attr deduction for non-IPO amendable functions
If the function is non-IPO amendable we do skip most attributes/AAs. However, if an AA has a isImpliedByIR that can deduce the at
[Attributor] Allow IR-attr deduction for non-IPO amendable functions
If the function is non-IPO amendable we do skip most attributes/AAs. However, if an AA has a isImpliedByIR that can deduce the attribute from other attributes, we can run those. For now, we manually enable them, if we have more later we can use some automation/flag.
show more ...
|
#
23dafbb1 |
| 19-Jun-2023 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] Remove the iteration count verification
It was never really useful to track #iterations, though it helped during the initial development. What we should track, in a follow up, are poten
[Attributor] Remove the iteration count verification
It was never really useful to track #iterations, though it helped during the initial development. What we should track, in a follow up, are potentially #updates. That is also what we should restrict instead of the #iterations.
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
56be9123 |
| 06-Jan-2023 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor][OpenMP][NFC] Cleanup tests via update script
|
#
4f4787e3 |
| 23-Dec-2022 |
Nikita Popov <npopov@redhat.com> |
[Attributor] Convert some tests to opaque pointers (NFC)
These were converted without adjustments.
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2 |
|
#
846709b2 |
| 23-Sep-2022 |
Nikita Popov <npopov@redhat.com> |
[Attribute] Clean up test prefixes (NFC)
Now that the legacy PM is no longer tested, the huge matrix of test prefixes used by attributor tests is no longer needed and very confusing for the casual r
[Attribute] Clean up test prefixes (NFC)
Now that the legacy PM is no longer tested, the huge matrix of test prefixes used by attributor tests is no longer needed and very confusing for the casual reader. Reduce the prefixes down to just CHECK, TUNIT and CGSCC.
show more ...
|
Revision tags: llvmorg-15.0.1 |
|
#
99c9b37d |
| 19-Sep-2022 |
Sebastian Peryt <sebastian.peryt@intel.com> |
[NFC][1/n] Remove -enable-new-pm=0 flags from lit tests
This is the first patch in a series intended for removing flag -enable-new-pm=0 from lit tests. This is part of a bigger effort of completely
[NFC][1/n] Remove -enable-new-pm=0 flags from lit tests
This is the first patch in a series intended for removing flag -enable-new-pm=0 from lit tests. This is part of a bigger effort of completely removing legacy code related to legacy pass manager in favor of currently default new pass manager.
In this patch flag has been removed only from tests where no significant change has been required because checks has been duplicated for both PMs.
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D134150
show more ...
|
Revision tags: llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
#
bf789b19 |
| 21-Jun-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] Replace AAValueSimplify with AAPotentialValues
For the longest time we used `AAValueSimplify` and `genericValueTraversal` to determine "potential values". This was problematic for many
[Attributor] Replace AAValueSimplify with AAPotentialValues
For the longest time we used `AAValueSimplify` and `genericValueTraversal` to determine "potential values". This was problematic for many reasons: - We recomputed the result a lot as there was no caching for the 9 locations calling `genericValueTraversal`. - We added the idea of "intra" vs. "inter" procedural simplification only as an afterthought. `genericValueTraversal` did offer an option but `AAValueSimplify` did not. Thus, we might end up with "too much" simplification in certain situations and then gave up on it. - Because `genericValueTraversal` was not a real `AA` we ended up with problems like the infinite recursion bug (#54981) as well as code duplication.
This patch introduces `AAPotentialValues` and replaces the `AAValueSimplify` uses with it. `genericValueTraversal` is folded into `AAPotentialValues` as are the instruction simplifications performed in `AAValueSimplify` before. We further distinguish "intra" and "inter" procedural simplification now.
`AAValueSimplify` was not deleted as we haven't ported the re-materialization of instructions yet. There are other differences over the former handling, e.g., we may not fold trivially foldable instructions right now, e.g., `add i32 1, 1` is not folded to `i32 2` but if an operand would be simplified to `i32 1` we would fold it still.
We are also even more aware of function/SCC boundaries in CGSCC passes, which is good even if some tests look like they regress.
Fixes: https://github.com/llvm/llvm-project/issues/54981
Note: A previous version was flawed and consequently reverted in 6555558a80589d1c5a1154b92cc3af9495f8f86c.
show more ...
|
#
f6e0c05e |
| 08-Jul-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
Revert "[Attributor] Replace AAValueSimplify with AAPotentialValues"
This reverts commit f17639ea0cd30f52ac853ba2eb25518426cc3bb8 as three AMDGPU tests haven't been updated. Will need to verify the
Revert "[Attributor] Replace AAValueSimplify with AAPotentialValues"
This reverts commit f17639ea0cd30f52ac853ba2eb25518426cc3bb8 as three AMDGPU tests haven't been updated. Will need to verify the changes are not regressions we should avoid.
show more ...
|
#
f17639ea |
| 21-Jun-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] Replace AAValueSimplify with AAPotentialValues
For the longest time we used `AAValueSimplify` and `genericValueTraversal` to determine "potential values". This was problematic for many
[Attributor] Replace AAValueSimplify with AAPotentialValues
For the longest time we used `AAValueSimplify` and `genericValueTraversal` to determine "potential values". This was problematic for many reasons: - We recomputed the result a lot as there was no caching for the 9 locations calling `genericValueTraversal`. - We added the idea of "intra" vs. "inter" procedural simplification only as an afterthought. `genericValueTraversal` did offer an option but `AAValueSimplify` did not. Thus, we might end up with "too much" simplification in certain situations and then gave up on it. - Because `genericValueTraversal` was not a real `AA` we ended up with problems like the infinite recursion bug (#54981) as well as code duplication.
This patch introduces `AAPotentialValues` and replaces the `AAValueSimplify` uses with it. `genericValueTraversal` is folded into `AAPotentialValues` as are the instruction simplifications performed in `AAValueSimplify` before. We further distinguish "intra" and "inter" procedural simplification now.
`AAValueSimplify` was not deleted as we haven't ported the re-materialization of instructions yet. There are other differences over the former handling, e.g., we may not fold trivially foldable instructions right now, e.g., `add i32 1, 1` is not folded to `i32 2` but if an operand would be simplified to `i32 1` we would fold it still.
We are also even more aware of function/SCC boundaries in CGSCC passes, which is good even if some tests look like they regress.
Fixes: https://github.com/llvm/llvm-project/issues/54981
Note: A previous version was flawed and consequently reverted in 6555558a80589d1c5a1154b92cc3af9495f8f86c.
show more ...
|
Revision tags: llvmorg-14.0.5 |
|
#
6555558a |
| 09-Jun-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
Revert "[Attributor] Replace AAValueSimplify with AAPotentialValues"
This reverts commit da50dab1ae111e9e6cb0248a47a038b17f798705.
Patch broke AMD GPU OpenMP offload buildbots. https://lab.llvm.org
Revert "[Attributor] Replace AAValueSimplify with AAPotentialValues"
This reverts commit da50dab1ae111e9e6cb0248a47a038b17f798705.
Patch broke AMD GPU OpenMP offload buildbots. https://lab.llvm.org/buildbot/#/builders/193/builds/13246
show more ...
|
Revision tags: llvmorg-14.0.4 |
|
#
da50dab1 |
| 10-May-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] Replace AAValueSimplify with AAPotentialValues
For the longest time we used `AAValueSimplify` and `genericValueTraversal` to determine "potential values". This was problematic for many
[Attributor] Replace AAValueSimplify with AAPotentialValues
For the longest time we used `AAValueSimplify` and `genericValueTraversal` to determine "potential values". This was problematic for many reasons: - We recomputed the result a lot as there was no caching for the 9 locations calling `genericValueTraversal`. - We added the idea of "intra" vs. "inter" procedural simplification only as an afterthought. `genericValueTraversal` did offer an option but `AAValueSimplify` did not. Thus, we might end up with "too much" simplification in certain situations and then gave up on it. - Because `genericValueTraversal` was not a real `AA` we ended up with problems like the infinite recursion bug (#54981) as well as code duplication.
This patch introduces `AAPotentialValues` and replaces the `AAValueSimplify` uses with it. `genericValueTraversal` is folded into `AAPotentialValues` as are the instruction simplifications performed in `AAValueSimplify` before. We further distinguish "intra" and "inter" procedural simplification now.
`AAValueSimplify` was not deleted as we haven't ported the re-materialization of instructions yet. There are other differences over the former handling, e.g., we may not fold trivially foldable instructions right now, e.g., `add i32 1, 1` is not folded to `i32 2` but if an operand would be simplified to `i32 1` we would fold it still.
We are also even more aware of function/SCC boundaries in CGSCC passes, which is good.
Fixes: https://github.com/llvm/llvm-project/issues/54981
show more ...
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2 |
|
#
39a68cc0 |
| 15-Apr-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
Revert "[Attributor] CGSCC pass should not recompute results outside the SCC"
This reverts commit 0d7f81e31315f8cda56ce6fde5ff5145e0325c51, it caused the AMDGPU tests that use the Attributor to fail.
|
#
0d7f81e3 |
| 12-Apr-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] CGSCC pass should not recompute results outside the SCC
When we run the CGSCC pass we should only invest time on the SCC. We can initialize AAs with information from the module slice bu
[Attributor] CGSCC pass should not recompute results outside the SCC
When we run the CGSCC pass we should only invest time on the SCC. We can initialize AAs with information from the module slice but we should not update those AAs.
show more ...
|
Revision tags: llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
#
f3ad8cf0 |
| 10-Mar-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] Cleanup manifest and liveness for CGSCC passes
There was some ad-hoc handling of liveness and manifest to avoid breaking CGSCC guarantees. Things always slipped through though. This cle
[Attributor] Cleanup manifest and liveness for CGSCC passes
There was some ad-hoc handling of liveness and manifest to avoid breaking CGSCC guarantees. Things always slipped through though. This cleanup will:
1) Prevent us from manifesting any "information" outside the CGSCC. This might be too conservative but we need to opt-in to annotation not try to avoid some problematic ones. 2) Avoid running any liveness analysis outside the CGSCC. We did have some AAIsDeadFunction handling to this end but we need this for all AAIsDead classes. The reason is that AAIsDead information is only correct if we actually manifest it, since we don't (see point 1) we cannot actually derive/use it at all. We are currently trying to avoid running any AA updates outside the CGSCC but that seems to impact things quite a bit. 3) Assert, don't check, that our modifications (during cleanup) modifies only CGSCC functions.
show more ...
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
#
d1186ce7 |
| 30-Jan-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] Make interprocedural value explicit in genericValueTraversal
genericValueTraversal can look through arguments and allow value simplification across function boundaries. In fact, the lat
[Attributor] Make interprocedural value explicit in genericValueTraversal
genericValueTraversal can look through arguments and allow value simplification across function boundaries. In fact, the latter already happened unchecked. With this change we allow the user of genericValueTraversal to opt-out of interprocedural traversal if required. We explicitly look through arguments now which helps to do various things, incl. the propagation of constants into OpenMP parallel regions (on the host).
show more ...
|
#
a1db0e52 |
| 01-Feb-2022 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor][FIX] Liveness handling in the isAssumedDead helpers
This fixes a conceptual problem with our AAIsDead usage which conflated call site liveness with call site return value liveness. With
[Attributor][FIX] Liveness handling in the isAssumedDead helpers
This fixes a conceptual problem with our AAIsDead usage which conflated call site liveness with call site return value liveness. Without the fix tests would obviously miscompile as we make genericValueTraversal more powerful (in a follow up). The effects on the tests are mixed but mostly marginal. The most prominent one is the lack of `noreturn` for functions. The reason is that we make entire blocks live at the same time (for time reasons). Now that we actually look at the block liveness, which we need to do, the return instructions are live and will survive. As an example, `noreturn_async.ll` has been modified to retain the `noreturn` even with block granularity. We could address this easily but there is little need in practice.
show more ...
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
#
5bb75629 |
| 21-Oct-2021 |
Nikita Popov <nikita.ppv@gmail.com> |
[Attributor] Generalize GEP construction
Make use of the getGEPIndicesForOffset() helper for creating GEPs. This handles arrays as well, uses correct GEP index types and reduces code duplication.
D
[Attributor] Generalize GEP construction
Make use of the getGEPIndicesForOffset() helper for creating GEPs. This handles arrays as well, uses correct GEP index types and reduces code duplication.
Differential Revision: https://reviews.llvm.org/D112263
show more ...
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
#
c2281f15 |
| 12-Jul-2021 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor] Introduce AAPointerInfo
This patch introduces AAPointerInfo which tracks the uses of a pointer and places them in "bins" based on their offset from the base and access size.
As with ot
[Attributor] Introduce AAPointerInfo
This patch introduces AAPointerInfo which tracks the uses of a pointer and places them in "bins" based on their offset from the base and access size.
As with other AAs, any pointer can be tracked but it is up to the user to make sense of the results. The user in this patch is AAValueSimplify and AAPotentialValues which both utilize AAPointerInfo to determine the value of a load. For now, this is restricted to loads of allocas and internal globals. Through the use of AAPointerInfo and the "bins" we can track struct members separately. The users also know that storing only zeros (at unknown indices) will result in loading only 0 (from unknown indices). Other than that, the users are flow and context insensitive (for now).
To deal with the "bins" more easily, AAPointerInfo provides a forallInterfearingAccesses that applies a callback on all accesses that might interfere with a given load or store.
Differential Revision: https://reviews.llvm.org/D104432
show more ...
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
9c2074dc |
| 12-Mar-2021 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor][NFC] Update tests after D94741
The update_test_checks script can now check for global symbols and is able to handle them properly when they differ across prefixes, e.g., attribute #0 mi
[Attributor][NFC] Update tests after D94741
The update_test_checks script can now check for global symbols and is able to handle them properly when they differ across prefixes, e.g., attribute #0 might be different in different runs.
This patch simply updates all the Attributor tests with the new script.
Reviewed By: sstefan1
Differential Revision: https://reviews.llvm.org/D97906
show more ...
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
#
d39f574d |
| 29-Oct-2020 |
Johannes Doerfert <johannes@jdoerfert.de> |
[Attributor][FIX] Properly promote arguments pointers to arrays
When we promote pointer arguments we did compute a wrong offset and use a wrong type for the array case.
Bug reported and reduced by
[Attributor][FIX] Properly promote arguments pointers to arrays
When we promote pointer arguments we did compute a wrong offset and use a wrong type for the array case.
Bug reported and reduced by Whitney Tsang <whitneyt@ca.ibm.com>.
show more ...
|