Follow-up to #140494
`shouldForceRelocation` is conservative and produces redundant
relocations.
For example, RISCVAsmBackend::ForceRelocs (introduced to support mixed
relax/norelax code) leads to redundant relocations in the following
example adapted from #77436
```
.option norelax
j label
// For assembly input, RISCVAsmParser::ParseInstruction sets ForceRelocs (https://reviews.llvm.org/D46423).
// For direct object emission, RISCVELFStreamer sets ForceRelocs (#77436)
.option relax
call foo // linker-relaxable
.option norelax
j label // redundant relocation due to ForceRelocs
.option relax
label:
```
Root problem: The `isSymbolRefDifferenceFullyResolvedImpl` condition in
MCAssembler::evaluateFixup does not check whether two locations are
separated by a fragment whose size can be indeterminate due to linker
instruction (e.g. MCDataFragment with relaxation, or MCAlignFragment
due to indeterminate start offst).
This patch
* Updates the fragment walk code in
`attemptToFoldSymbolOffsetDifference` to treat MCRelaxableFragment
(for --riscv-asm-relax-branches) as fixed size after finishLayout.
* Adds a condition in `addReloc` to complement
`isSymbolRefDifferenceFullyResolvedImpl`.
* Removes the no longer needed `shouldForceRelocation`.
This fragment walk code path handles nicely handles
mixed relax/norelax case from
https://discourse.llvm.org/t/possible-problem-related-to-subtarget-usage/75283
and allows us to remove `MCSubtargetInfo` argument (#73721) as a follow-up.
This fragment walk code should be avoided in the absence of
linker-relaxable fragments within the current section.
Adjust two bolt/test/RISCV tests (#141310)
Pull Request: https://github.com/llvm/llvm-project/pull/140692
The original implementation will create two intermediate AffineMap in
the context, calling this compose function with different values
multiple times will occupy a lot of memory.
To improve the performance, we can call the AffineExpr::replace
directly, so we don't need to store all combinations of values in the
context.
The builtin is documented to copy `count` elements, but the implementation
copies `count` bytes. Fix that.
Reviewers: cor3ntin, ojhunt
Pull Request: https://github.com/llvm/llvm-project/pull/140312
This patch implements the business logic for setupTemplateValue, which
was split from #133161. The implementation configures the relative path
relationships between the various HTML components, and prepares them
prior to their use in the generator.
Co-authored-by: Peter Chou <peter.chou@mail.utoronto.ca>
Split from #133161. This patch provides the implementation of a number
of extractValue overloads used with the different types of Info.
The new helper functions extract the relevant information from the
different *Infos and inserts them into the correct fields of the JSON
values that will be used with the specific Mustache templates, which
will land separately.
Co-authored-by: Peter Chou <peter.chou@mail.utoronto.ca>
This adds alignment support for GlobalOp, LoadOp, and StoreOp.
Tests which failed because cir.store/cir.load now print alignment were
updated with wildcard matches, except where the alignment was relevant
to the test. Tests which check for cir.store/cir.load in cases that
don't have explicit alignment were not updated.
New tests for alignment are alignment.c, align-load.c, and
align-store.c.
This is a follow on to 9b4de7 which handles the fixed vector cases. In
retrospect, this is simple enough if probably should have just been part
of the original commit, but oh well.
We've added a new macro for the unversioned `namespace std` cases in
#133009, but it seems we've missed a few places. This fixes the places I
just found.
Similar to #141261.
These aren't easy to test without write MIR tests in areas we don't
currently have tests. I'm not sure we use X0_Pair anywhere today.
I'm going to try to migrate RISCVMakeCompressible to use copyToReg so we
can share that code instead of basically duplicating it.
I'm still concerned that target independent code may fold an
extract_subreg operation and get an incorrect register if we do start
using X0_Pair. We may have to special case dummy_reg_pair_with_x0 in the
encoder and printer to be safe.
Fixes the changes introduced in
https://github.com/llvm/llvm-project/pull/126675 and subsequently
reverted by https://github.com/llvm/llvm-project/pull/126934 .
Originally, I mistakenly put the `install` in the wrong location (should
have been in the `add_clang_tool` macro) which slipped through testing.
I've verified locally using the same CMake configure options.
For reference:
* **CMake Configure**
```
cmake -B build -S llvm -GNinja -DLLVM_ENABLE_PROJECTS="llvm;clang;lld;compiler-rt" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PDB=ON -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl
```
* **Error**
```
TARGET_PDB_FILE is allowed only for targets with linker created artifacts.
```
While the current test exercised the deadlock behavior prior to #131756,
deadlock still can occur intermittently. Since this results in test
flakes in CI, we disable this test until the locking behavior can be
fixed in the runtime. See #140646 for details.
Fixes#59812
The names of conversion functions of template type parameters were being
emitted as "type-parameter-N-M". Now we check if the conversion type is
a TemplateTypeParmType and reconstruct the source name.
As far as I understand any binary op with poison as either operand will
constant fold to poison, so this check will never trigger.
`llvm::ConstantFoldBinaryInstruction` seems to confirm this?
I think this ended up getting left behind because originally
shufflevectors with undef indices produced undef elements, and we
couldn't pull the shuffle across some binops like `or undef, -1 --> -1`.
This code was added in 8c655150827b5d56772e628994db08441c554097 to
partially fix it and further extended in
f7499011ca29bebeda7c9d79d79b290cf0b8b46d, originally checking for undef
but changed to check for poison in cd54c47424456
But nowadays shufflevectors with undef indices are treated as poison
indices as of 575fdea70a86f68b0d303a9a3273fc47f810628a, and so produce
poison elements, so this is no longer an issue
This patch adds initial support for Integrated Distributed ThinLTO
(DTLTO) in LLVM, which manages distribution internally during the
traditional link step. This enables compatibility with any build
system that supports in-process ThinLTO. In contrast, existing
approaches to distributed ThinLTO, which split the thin-link
(--thinlto-index-only), backend compilation, and final link into
separate steps, require build system support, e.g. Bazel.
This patch implements the core DTLTO mechanism, which enables
delegation of ThinLTO backend jobs to an external process (the
distributor). The distributor can then manage job distribution through
systems like Incredibuild. A generic JSON interface is used to
communicate with the distributor, allowing for the creation of new
distributors (and thus integration with different distribution
systems) without modifying LLVM.
Please see llvm/docs/dtlto.rst for more details.
RFC: https://discourse.llvm.org/t/rfc-integrated-distributed-thinlto/69641
Design Review: https://github.com/llvm/llvm-project/pull/126654
Without this patch the !subst in the test drops the name "$frag" from
(one_frag:$frag ...) and returns:
```
(set FPR32_NEW:$dst, (one_frag FPR32_NEW:$a, FPR32_NEW:$b))
```
In #138062 it was brought up that this was an anti-pattern. We'll need
to Migrate all of the mustache unittests that need to read template
files to lit tests, and disable them until tool support lands.
Update the stdin <-> stdout client name to `stdio`. I noticed on macOS
if I get a crash report from lldb-dap the `/` in the client name causes
some thread names to be reported without the full name. For example
`Thread 6 Crashed:: */stdout.event_handler`. Switching to `stdio` I
think is still clear and not truncated in the macOS crash reports.
Previously we would add any ELF that contained a build id regardless
whether the ELF contained symbols or not. This works for Android since
soong will strip the symbols into a new directory. However other
build systems, like BUCK, will write the stripped file in the same
directory as the unstripped file. This would cause the hwasan_symbolize
script sometimes add then stripped ELF to its index and ignore the
symbolized ELF. The logic has now been changed to only add ELFs that
contain symbols to the index. If two symbolized ELFs are encountered
with the same build id, we now exit out with an error.
Fixes#135966
---------
Co-authored-by: Stefan Bossbaly <sboss@meta.com>
This fixes finding the builtins library for arm64ec in tests.
This matches a corresponding condition added in cmake in
3764ba23484afda683eea390407103e609ef4354.
