LLVM and SPIRV-LLVM-Translator pulldown (WW25) #3934
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ime. It was found by chance revealing discrepancy between comment (few lines above), the condition and how re-ordering of instruction is done inside the if statement it guards. The condition was always evaluated to true. Differential Revision: https://reviews.llvm.org/D104064
Update LLDB for thew new Objective-C hash table layout in the dyld shared cache found in macOS Monterey. rdar://72863911
## Introduction
This proposal describes the new op to be added to the `std` (and later moved `memref`)
dialect called `alloca_scope`.
## Motivation
Alloca operations are easy to misuse, especially if one relies on it while doing
rewriting/conversion passes. For example let's consider a simple example of two
independent dialects, one defines an op that wants to allocate on-stack and
another defines a construct that corresponds to some form of looping:
```
dialect1.looping_op {
%x = dialect2.stack_allocating_op
}
```
Since the dialects might not know about each other they are going to define a
lowering to std/scf/etc independently:
```
scf.for … {
%x_temp = std.alloca …
… // do some domain-specific work using %x_temp buffer
… // and store the result into %result
%x = %result
}
```
Later on the scf and `std.alloca` is going to be lowered to llvm using a
combination of `llvm.alloca` and unstructured control flow.
At this point the use of `%x_temp` is bound to either be either optimized by
llvm (for example using mem2reg) or in the worst case: perform an independent
stack allocation on each iteration of the loop. While the llvm optimizations are
likely to succeed they are not guaranteed to do so, and they provide
opportunities for surprising issues with unexpected use of stack size.
## Proposal
We propose a new operation that defines a finer-grain allocation scope for the
alloca-allocated memory called `alloca_scope`:
```
alloca_scope {
%x_temp = alloca …
...
}
```
Here the lifetime of `%x_temp` is going to be bound to the narrow annotated
region within `alloca_scope`. Moreover, one can also return values out of the
alloca_scope with an accompanying `alloca_scope.return` op (that behaves
similarly to `scf.yield`):
```
%result = alloca_scope {
%x_temp = alloca …
…
alloca_scope.return %myvalue
}
```
Under the hood the `alloca_scope` is going to lowered to a combination of
`llvm.intr.stacksave` and `llvm.intr.strackrestore` that are going to be invoked
automatically as control-flow enters and leaves the body of the `alloca_scope`.
The key value of the new op is to allow deterministic guaranteed stack use
through an explicit annotation in the code which is finer-grain than the
function-level scope of `AutomaticAllocationScope` interface. `alloca_scope`
can be inserted at arbitrary locations and doesn’t require non-trivial
transformations such as outlining.
## Which dialect
Before memref dialect is split, `alloca_scope` can temporarily reside in `std`
dialect, and later on be moved to `memref` together with the rest of
memory-related operations.
## Implementation
An implementation of the op is available [here](https://reviews.llvm.org/D97768).
Original commits:
* Add initial scaffolding for alloca_scope op
* Add alloca_scope.return op
* Add no region arguments and variadic results
* Add op descriptions
* Add failing test case
* Add another failing test
* Initial implementation of lowering for std.alloca_scope
* Fix backticks
* Fix getSuccessorRegions implementation
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D97768
Check applied to unbounded (incomplete) arrays and pointers to spot cases where the computed address is beyond the largest possible addressable extent of the array, based on the address space in which the array is delcared, or which the pointer refers to. Check helps to avoid cases of nonsense pointer math and array indexing which could lead to linker failures or runtime exceptions. Of particular interest when building for embedded systems with small address spaces. This is version 2 of this patch -- version 1 had some testing issues due to a sign error in existing code. That error is corrected and lit test for this chagne is extended to verify the fix. Originally reviewed/accepted by: aaron.ballman Original revision: https://reviews.llvm.org/D86796 Reviewed By: aaron.ballman, ebevhan Differential Revision: https://reviews.llvm.org/D88174
Since the call lowering code now tries to respect the tablegen reported argument types, this is no longer necessary.
Differential Revision: https://reviews.llvm.org/D102020
Currently, the compiler-rt build system checks only whether __X86_64 is defined to determine whether the default compiler-rt target arch is x86_64. Since x32 defines __X86_64 as well, we must also check that the default pointer size is eight bytes and not four bytes to properly detect a 64-bit x86_64 compiler-rt default target arch. Reviewed By: hvdijk, vitalybuka Differential Revision: https://reviews.llvm.org/D99988
…tterInst() Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D103480
Also:
- add driver test (fsanitize-use-after-return.c)
- add basic IR test (asan-use-after-return.cpp)
- (NFC) cleaned up logic for generating table of __asan_stack_malloc
depending on flag.
for issue: google/sanitizers#1394
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D104076
It's possible to have several USE statements for the same module that have different mixes of rename clauses and ONLY clauses. The presence of a rename cause has the effect of hiding a previously associated name, and the presence of an ONLY clause forces the name to be visible even in the presence of a rename. I fixed this by keeping track of the names that appear on rename and ONLY clauses. Then, when processing the USE association of a name, I check to see if it previously appeared in a rename clause and not in a USE clause. If so, I remove its USE associated symbol. Also, when USE associating all of the names in a module, I do not USE associate names that have appeared in rename clauses. I also added a test. Differential Revision: https://reviews.llvm.org/D104130
Fixes the order of template arguments passed to the `PassWrapper`. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D104132
This is a similarity visualization tool that accepts a Module and passes it to the IRSimilarityIdentifier. The resulting SimilarityGroups are output in a JSON file. Tests are found in test/tools/llvm-sim and check for the file not found, a bad module, and that the JSON is created correctly. Reviewers: paquette, jroelofs, MaskRay Recommit of: 15645d0 to fix linking errors. Differential Revision: https://reviews.llvm.org/D86974
…h format attribute This is useful for APIs that want to accept an attributed NSString as their format string rdar://79163229
I don't like landing this change, but it's an acknowledgement of a practical reality. Despite not having well specified semantics for inttoptr and ptrtoint involving non-integral pointer types, they are used in practice. Here's a quick summary of the current pragmatic reality: * I happen to know that the main external user of non-integral pointers has effectively disabled the verifier rules. * RS4GC (the lowering pass for abstract GC machine model which is the key motivation for non-integral pointers), even supports them. We just have all the tests using an integral pointer space to let the verifier run. * Certain idioms (such as alignment checks for alignment N, where any relocation is guaranteed to be N byte aligned) are fine in practice. * As implemented, inttoptr/ptrtoint are CSEd and are not control dependent. This means that any code which is intending to check a particular bit pattern at site of use must be wrapped in an intrinsic or external function call. This change allows them in the Verifier, and updates the LangRef to specific them as implementation dependent. This allows us to acknowledge current reality while still leaving ourselves room to punt on figuring out "good" semantics until the future.
This reverts commit f47d00c.
…e state. Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D104068
…were already autogenerated The motivation is that the update script has at least two deviations (`<...>@GOT`/`<...>@PLT`/ and not hiding pointer arithmetics) from what pretty much all the checklines were generated with, and most of the tests are still not updated, so each time one of the non-up-to-date tests is updated to see the effect of the code change, there is a lot of noise. Instead of having to deal with that each time, let's just deal with everything at once. This has been done via: ``` cd llvm-project/llvm/test/CodeGen/X86 grep -rl "; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py" | xargs -L1 <...>/llvm-project/llvm/utils/update_llc_test_checks.py --llc-binary <...>/llvm-project/build/bin/llc ``` Not all tests were regenerated, however.
Every invocation this was copying the Mapper for no reason. Take a const ref instead. Author: lanza Reviewers: AndrewLitteken, plofti, paquette, Differential Review: https://reviews.llvm.org/D92532
… with -fsanitize-address-use-after-return (NFC) for issue: google/sanitizers#1394 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D104146
…NFC) for issue: google/sanitizers#1394 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D104152
It's a patch to fix ignoring of checksum info when translating compile unit Original commit: KhronosGroup/SPIRV-LLVM-Translator@0d8d4c4
Rely on the IRBuilder to fold into constant expressions if possible. Original commit: KhronosGroup/SPIRV-LLVM-Translator@a775597
Co-authored-by: Stuart Brady Original commit: KhronosGroup/SPIRV-LLVM-Translator@cb7a560
This revealed that OpINotEqual was missing from isSpecConstantOpAllowedOp. Test co-authored by Stuart Brady. Original commit: KhronosGroup/SPIRV-LLVM-Translator@43c071f
Using a different LLVM version to obtain the compile commands may cause inclusion of compiler flags that aren't recognized by the older version of clang-tidy. Original commit: KhronosGroup/SPIRV-LLVM-Translator@75e0b0e
Use LLVM expandMemMoveAsLoop function in case memmove intrinsic use has non-constant length. Original commit: KhronosGroup/SPIRV-LLVM-Translator@c4184ff
If a phi instruction uses result of __spirv_SpecConst() call which has not been translated yet, we created a OpForward instruction. Then we translated the call to OpSpecConstant and attached the SpecId decoration to it. After that, when we map LLVM value to SPIR-V values we detected that there is a OpForward instruction and replaced Id of OpSpecConstant with Id of the OpForward instruction, leaving the decoration targeted to non-existing instruction. To avoid this incorrect behaviour we should attach decorations after replacing OpForward instruction, i.e. in transDecoration method. Signed-off-by: Alexey Sotkin <alexey.sotkin@intel.com> Original commit: KhronosGroup/SPIRV-LLVM-Translator@de22867
These do not need any further implementation work. Original commit: KhronosGroup/SPIRV-LLVM-Translator@23a03d7
`OpSpecConstantOp` may be used outside of a basic block (for example in a variable initializer). Modify the `SPIRVSelect` constructor to accept a `nullptr` basic block. Use an IRBuilder when translating `OpSelect`, so that the resulting select expression will be created as a constant expression (and possibly constant-folded) where possible. Update some tests as the SPIR-V to LLVM translation now folds selects more aggressively due to the use of IRBuilder. Original commit: KhronosGroup/SPIRV-LLVM-Translator@be24f4e
|
/summary:run |
|
/summary:run |
vmaksimo
requested review from
AaronBallman,
AGindinson,
AlexeySachkov,
AlexeySotkin,
bader,
DenisBakhvalov,
elizabethandrews,
kbobrovs,
mdtoguchi,
mlychkov,
premanandrao and
sndmitriev
as code owners
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
LLVM: llvm/llvm-project@6c7be41
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@be24f4e