I've seen a few people try to enable opaque pointers with LLVM 14
already. While LLVM 14 has pretty good baseline support, there are
enough missing pieces that you're definitely going to hit assertion
failures if you try this.
Add some wording to make it clear what the support (or planned
support) for opaque/typed pointers is across LLVM 14, 15, and 16.
Extend the TypeWidenVector case of PromoteIntRes_BITCAST to work
with TypeSize directly rather than silently casting to unsigned.
To accomplish this I've extended TypeSize with an interface that
essentially allows TypeSize division when both operands have the
same number of dimensions.
There still exists combinations of scalable vector bitcasts that
cause compiler crashes. I call these out by adding "is missing"
entries to sve-bitcast.
Depends on D126957.
Fixes: #55114
Differential Revision: https://reviews.llvm.org/D127126
Bitcasting between unpacked scalable vector types of different
element counts is not a NOP because the live elements are laid out
differently.
01234567
e.g. nxv2i32 = XX??XX??
nxv4f16 = X?X?X?X?
Differential Revision: https://reviews.llvm.org/D126957
Find writability conflicts (writes to buffers that are not allowed to be written to) by checking SSA use-def chains. This is better than the current writability analysis, which is too conservative and finds false positives.
Differential Revision: https://reviews.llvm.org/D127256
The minimun bound for number of edits is the size difference between the 2 arrays.
If MaxEditDistance is smaller than this, we can bail out early without needing to traverse any of the arrays.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D127070
This makes the LLVM_ENABLE_PROJECTS mode (supported for compiler-rt, deprecated
(D112724) for libcxx/libcxxabi/libunwind) closer to
https://libcxx.llvm.org/BuildingLibcxx.html#bootstrapping-build .
The layout is arguably superior because different libraries of target triples
are in different directories, similar to GCC/Debian multiarch.
When LLVM_DEFAULT_TARGET_TRIPLE is x86_64-unknown-linux-gnu,
`lib/clang/15.0.0/lib/libclang_rt.asan-x86_64.a`
is moved to
`lib/clang/15.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a`.
In addition, if the host compiler supports -m32 (multilib),
`lib/clang/15.0.0/lib/libclang_rt.asan-i386.a`
is moved to
`lib/clang/15.0.0/lib/i386-unknown-linux-gnu/libclang_rt.asan.a`.
Reviewed By: mstorsjo, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D107799
Check supportsTypedPointers instead of hasSetOpaquePointersValue when query if has typed ptr.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D127268
Spliter will try to extend a live range into `r` slot for a use operand,
that's works on most situaion, however that not work correctly when the operand
has tied to def, and the def operand is early clobber.
Give an example to demo what's wrong:
0 %0 = ...
16 early-clobber %0 = Op %0 (tied-def 0), ...
32 ... = Op %0
Before extend:
%0 = [0r, 0d) [16e, 32d)
The point we want to extend is 0d to 16e not 16r in this case, but if
we use 16r here we will extend nothing because that already contained
in [16e, 32d).
This patch add check for detect such case and adjust the extend point.
Detailed explanation for testcase: https://reviews.llvm.org/D126047
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D126048
This is required for the distribution system for installing the
mlir-libraries component. This is copied from clang's equivalent
feature.
Differential Revision: https://reviews.llvm.org/D126837
Background:
When we construct coroutine frame, we would insert a dbg.declare
intrinsic for it:
```
%hdl = call void @llvm.coro.begin() ; would return coroutine handle
call void @llvm.dbg.declare(metadata ptr %hdl, metadata
![[DEBUG_VARIABLE: __coro_frame]], metadata !DIExpression())
```
And in the splitted coroutine, it looks like:
```
define void @coro_func.resume(ptr *hdl) {
entry.resume:
call void @llvm.dbg.declare(metadata ptr %hdl, metadata
![[DEBUG_VARIABLE: __coro_frame]], metadata !DIExpression())
}
```
And we would salvage the debug info by inserting a new alloca here:
```
define void @coro_func.resume(ptr %hdl) {
entry.resume:
%frame.debug = alloca ptr
call void @llvm.dbg.declare(metadata ptr %frame.debug, metadata
![[DEBUG_VARIABLE: __coro_frame]], metadata !DIExpression())
store ptr %hdl, %frame.debug
}
```
But now, the problem comes since the `dbg.declare` refers to the address
of that alloca instead of actual coroutine handle. I saw there are codes
to solve the problem but it only applies to complex expression only. I
feel if it is OK to relax the condition to make it work for
`__coro_frame`.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D126277
They are now `using` aliases and thus the comments about iplist are now
incorrect. Remove them here.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95210
This patch implements two most commonly used Global Offset Table relocations in
ELF/AARCH64: R_AARCH64_ADR_GOT_PAGE and R_AARCH64_LD64_GOT_LO12_NC. It
implements the GOT table manager by extending the existing
PerGraphGOTAndPLTStubsBuilder. A future patch will unify this with the MachO
implementation to produce a generic aarch64 got table manager.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D127057
I believe this should've been fixed with 4b15e665f8
which landed after this initial patch, but I reverted too early before I
saw the builder turn green again.
InstCombine tries to rewrite
%prod = mul nsw i64 %X, Scale
%acc = add nsw i64 %prod, Offset
%0 = alloca i8, i64 %acc, align 4
%1 = bitcast i8* %0 to i32*
Use ( %1 )
into
%prod = mul nsw i64 %X, Scale/4
%acc = add nsw i64 %prod, Offset/4
%0 = alloca i32, i64 %acc, align 4
Use (%0)
But it assumes Scale is unsigned, and performs an unsigned division.
So we should bail out if Scale cannot be interpreted as an unsigned safely.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D126546
Implement R_AARCH64_ABS64 relocation entry. This relocation type is generated
when creating a static function pointer to symbol.
Reviewed By: lhames, sgraenitz
Differential Revision: https://reviews.llvm.org/D126658
Implement R_AARCH64_LDST*_ABS_LO12_NC relocaiton entries by reusing PageOffset21
generic relocation edge. The difference between MachO backend is that in ELF,
the shift value is explicitly given by relocation type. lld generates the
relocation type that matches with instruction bitwidth, so getting the shift
value implicitly from instruction bytes should be fine in typical use cases.
This updates existing asan allocator settings to use the same allocator settings as what lsan uses for platforms where they already match.
Differential Revision: https://reviews.llvm.org/D126927
This way downstream tools that read sanitizer output can differentiate between OOM errors
reported by sanitizers from other sanitizer errors.
Changes:
- Introduce ErrorIsOOM for checking if a platform-specific error code from an "mmap" is an OOM err.
- Add ReportOOMError which just prepends this error message to the start of a Report call.
- Replace some Reports for OOMs with calls to ReportOOMError.
- Update necessary tests.
Differential Revision: https://reviews.llvm.org/D127161
If we don't demand low bits and it is valid to pre-shift a constant:
(C2 >> X) << C1 --> (C2 << C1) >> X
https://alive2.llvm.org/ce/z/_UzTMP
This is the reverse-order shift sibling to 82040d414b ( D127122 ).
It seems likely that we would want to add this to the SDAG version of
the code too to keep it on par with IR.
* The yaml input is inlined into the test file.
* Unnecessary members and fields are removed.
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D127235