Add support for import and translate.
MLIR does not support using basic block references outside a function
(like LLVM does), This PR does not consider changes to MLIR to that
respect. It instead introduces two new ops: `llvm.blockaddress` and
`llvm.blocktag`. Here's an example:
```
llvm.func @ba() -> !llvm.ptr {
%0 = llvm.blockaddress <function = @ba, tag = <id = 1>> : !llvm.ptr
llvm.br ^bb1
^bb1: // pred: ^bb0
llvm.blocktag <id = 1>
llvm.return %0 : !llvm.ptr
}
```
Value `%0` hold the address of block tagged as `id = 1` in function
`@ba`. Block tags need to be unique within a function and use of
`llvm.blockaddress` requires a matching tag in a `llvm.blocktag`.
A requested follow-up from
https://github.com/llvm/llvm-project/pull/130912 by @JDevlieghere to
control Darwin parallel image loading with the same
`target.parallel-module-load` that controls the POSIX dyld parallel
image loading. Darwin parallel image loading was introduced by
https://github.com/llvm/llvm-project/pull/110646.
This small change:
* removes
`plugin.dynamic-loader.darwin.experimental.enable-parallel-image-load`
and associated code.
* changes setting call site in
`DynamicLoaderDarwin::PreloadModulesFromImageInfos` to use the new
setting.
Tested by running `ninja check-lldb` and loading some targets.
Co-authored-by: Tom Yang <toyang@fb.com>
## What?
Implement `areInlineCompatible` for the SystemZ target using
FeatureBitset comparison.
## Why?
The default implementation in `TargetTransformInfoImpl.h` makes a string
comparison and only inlines when the target-cpu and the target-features
for caller and callee are the same. We are missing out on optimizations
when the callee has a subset of features of the caller.
## How?
Get the FeatureBitset of the caller and callee and check when callee is
a subset or equal to the caller's features. It's a similar
implementation to ARM, PowerPC...
## Testing?
Test cases check for when the callee is a subset of the caller, when
it's not a subset and when both are equals.
When calculating the layout for a cbuffer field, if that field is a
ConstantArrayType, desguar it before casting it to a ConstantArrayType.
Closes#134668
---------
Co-authored-by: Eli Friedman <efriedma@quicinc.com>
debugserver takes the address of a watchpoint exception and calculates
which watchpoint was responsible for it. There was an off-by-one error
in the range calculation which causes two watchpoints on consecutive
ranges to not correctly identify hits to the second watchpoint. The
result is that lldb wouldn't show the second watchpoint as ever being
hit.
Re-landing this test with a modification to only require two
watchpoints in the test, instead of four. If four watchpoints can
be set, it will test them.
rdar://145107575
Add a buffer_fat_ptr_load_lds intrinsic, by analogy with
global_load_lds, which enables using `ptr addrspace(7)` to set the rsrc
and offset arguments to raw_ptr_buffer_load_lds.
Static analysis detected that Demangler::demangleStringLiteral had a
potential overflow if not checking StringByteSize properly.
Added check to ensure that for wide string it is always even and that
there were the byte count did not mismatch the actual size of the
literal.
Fixes: https://github.com/llvm/llvm-project/issues/129970
Update VPlan::duplicate to add cloned exit blocks to ExitBlocks.
Currently there are no uses of the exit blocks after cloning so this is
NFC at the moment.
When attempting to instantiate `std::atomic` with a non trivially
copyable type, one gets errors from instantiating internals before the
actual static assertion that check the template parameter type
requirements.
The `verify` test for it had a `// ADDITIONAL_COMPILE_FLAGS: -Xclang
-verify-ignore-unexpected=error` directive to work around this issue.
The changes I propose enable us to drop that directive.
As I understand it, the `verify` test was misplaced so I moved it to
`test/{std -> libcxx}/atomics`.
(I ran into this while working on #121414 in which we would add another
static assertion in `__check_atomic_mandates`)
This reverts commit 21d912121c9f41385b165a736be787527f5bd7c2.
Failure on the aarch64 ubuntu bot when setting the 4th watchpoint;
may be a hardware limitation on that bot. I thought creating four
watchpoints would be generally safe, but I don't need to do that
for my test, will re-land without it.
debugserver takes the address of a watchpoint exception and calculates
which watchpoint was responsible for it. There was an off-by-one error
in the range calculation which causes two watchpoints on consecutive
ranges to not correctly identify hits to the second watchpoint. The
result is that lldb wouldn't show the second watchpoint as ever being
hit.
rdar://145107575
