[JITLink] Switch to SymbolStringPtr for Symbol names (#115796)

Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning
on the boundary between JITLink and ORC, and allows p

[JITLink] Switch to SymbolStringPtr for Symbol names (#115796)

Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning
on the boundary between JITLink and ORC, and allows pointer comparisons (rather
than string comparisons) between Symbol names. This should improve the
performance and readability of code that bridges between JITLink and ORC (e.g.
ObjectLinkingLayer and ObjectLinkingLayer::Plugins).

To enable use of SymbolStringPtr a std::shared_ptr<SymbolStringPool> is added to
LinkGraph and threaded through to its construction sites in LLVM and Bolt. All
LinkGraphs that are to have symbol names compared by pointer equality must point
to the same SymbolStringPool instance, which in ORC sessions should be the pool
attached to the ExecutionSession.
---------

Co-authored-by: Lang Hames <lhames@gmail.com>

show more ...

[JITLink][RISCV] Use hashmap to find PCREL_HI20 edge (#78849)

As noted in issues #68594 and #73935, `JITLink/RISCV/ELF_ehframe.s`
fails with libstdc++'s expensive checks because `getRISCVPCRelHi20`

[JITLink][RISCV] Use hashmap to find PCREL_HI20 edge (#78849)

As noted in issues #68594 and #73935, `JITLink/RISCV/ELF_ehframe.s`
fails with libstdc++'s expensive checks because `getRISCVPCRelHi20`
calls `std::equal_range` on the edges which may not be ordered by their
offset. Instead let `ELFJITLinker_riscv` build a hashmap of all edges
with type `R_RISCV_PCREL_HI20` that can be looked up in constant time.

Closes #73935

show more ...

[RISCV] Only set Zca flag for EF_RISCV_RVC in ELFObjectFileBase::getRISCVFeatures(). (#80928)

This code appears to be a hack to set the features to include compressed
instructions if the ELF EFLAGS

[RISCV] Only set Zca flag for EF_RISCV_RVC in ELFObjectFileBase::getRISCVFeatures(). (#80928)

This code appears to be a hack to set the features to include compressed
instructions if the ELF EFLAGS flags bit is present, but the ELF
attribute for the ISA string is no present or not accurate.

We can't remove the hack because llvm-mc doesn't create ELF attributes
by default so a lot of tests fail to disassembler properly. Using clang
as the assembler does set the attributes.

This patch changes the hack to only set Zca since that is the minimum
implied by the flag. Setting anything else potentially conflicts with
the ISA string containing Zcmp or Zcmt.

JITLink also needs to be updated to recognize Zca in addition to C.

show more ...

[JITLink][RISCV] Implement eh_frame handling (#68253)

This requires adding a `NegDelta32` edge kind that cannot be mapped to
existing relocations.

Co-authored-by: Job Noorman <jnoorman@igalia.co

[JITLink][RISCV] Implement eh_frame handling (#68253)

This requires adding a `NegDelta32` edge kind that cannot be mapped to
existing relocations.

Co-authored-by: Job Noorman <jnoorman@igalia.com>

show more ...

[llvm] Use llvm::is_contained (NFC)

[JITLink][RISCV] Fix use-after-free in relax

Finalization of relaxation calls `finalizeBlockRelax` for every block in
the graph. This function, however, would iterate over //all// blocks in
the grap

[JITLink][RISCV] Fix use-after-free in relax

Finalization of relaxation calls `finalizeBlockRelax` for every block in
the graph. This function, however, would iterate over //all// blocks in
the graph to remove `AlignRelaxable` edges. Since pointers to those
edges would still be stored in `RelaxEdges`, this caused a
use-after-free for graphs with multiple blocks.

This patch fixes this by only iterating over the edges of the current
block in `finalizeBlockRelax`.

Reviewed By: StephenFan

Differential Revision: https://reviews.llvm.org/D154844

show more ...

[JITLink][RISCV] Move relax to PostAllocationPasses

`JITLinkContext` is notified (using `notifyResolved`) of the final
symbol addresses after allocating memory and running the post-allocation
passes

[JITLink][RISCV] Move relax to PostAllocationPasses

`JITLinkContext` is notified (using `notifyResolved`) of the final
symbol addresses after allocating memory and running the post-allocation
passes. However, linker relaxation, which can cause symbol addresses to
change, was run during the pre-fixup passes. This causes users of
JITLink (e.g., ORC) to pick-up wrong symbol addresses when linker
relaxation was enabled.

This patch fixes this by running relaxation during the post-allocation
passes.

Fixes #63671

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D154501

show more ...

[JITLink] Use SubtargetFeatures to store features in LinkGraph

D149522 introduced target features to LinkGraph. However, to avoid a
public dependency on MC, the features were stored in a std::vector

[JITLink] Use SubtargetFeatures to store features in LinkGraph

D149522 introduced target features to LinkGraph. However, to avoid a
public dependency on MC, the features were stored in a std::vector
instead of using SubtargetFeatures directly.

Since SubtargetFeatures was moved from MC to TargetParser (D150549), we
can now use it directly to store the features. This patch implements
that and removes the (private) dependency on MC.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D153749

show more ...

[JITLink][RISCV] Adjust offsets of non-relaxable edges

The relaxation algorithm used to only update offsets of relaxable edges.
This caused non-relaxable edges that appear after a relaxed instructio

[JITLink][RISCV] Adjust offsets of non-relaxable edges

The relaxation algorithm used to only update offsets of relaxable edges.
This caused non-relaxable edges that appear after a relaxed instruction
to have an incorrect offset and be applied at the wrong location. This
patch fixes this by updating the offsets of all edges.

Note that this bug was caused by an incorrect translation of LLD's
relaxation algorithm. LLD always uses all edges during relaxation while
I decided to filter-out relaxable edges to prevent having to iterate
non-relaxable edges at each step. However, this had the side-effect of
only updating offsets of relaxable edges. This patch leaves the
filtering of relaxable edges as-is but iterates all edges when updating
offsets.

Reviewed By: StephenFan

Differential Revision: https://reviews.llvm.org/D153515

show more ...

[JITLink][RISCV] Expose relaxation pass publicly

This is useful for contexts where shouldAddDefaultTargetPasses returns
false but that still want to perform relaxation.

Reviewed By: StephenFan

Dif

[JITLink][RISCV] Expose relaxation pass publicly

This is useful for contexts where shouldAddDefaultTargetPasses returns
false but that still want to perform relaxation.

Reviewed By: StephenFan

Differential Revision: https://reviews.llvm.org/D153538

show more ...

[JITLink][RISCV] Support relaxable edges without relaxation pass

Relaxable edges are created unconditionally, even when the relaxation
pass will not run. However, they were not recognized by applyFi

[JITLink][RISCV] Support relaxable edges without relaxation pass

Relaxable edges are created unconditionally, even when the relaxation
pass will not run. However, they were not recognized by applyFixup
causing them to not be applied.

To support configurations without the relaxation pass, this patch adds
these relaxable edges to applyFixup:
- CallRelaxable: Can be treated as R_RISCV_CALL
- AlignRelaxable: Can simply be ignored

An alternative could be to unconditionally run the relaxation pass, even
in contexts where shouldAddDefaultTargetPasses returns false. However, I
could imagine there being use cases for disabling relaxation which
wouldn't be possible anymore then.

Reviewed By: StephenFan

Differential Revision: https://reviews.llvm.org/D153541

show more ...

[JITLink][RISCV] Consider relaxable call edges for PLT edges

For linker relaxation (D149526), a new edge kind (`CallRelaxable`) was
introduced. However, this new kind was not taken into account by
`

[JITLink][RISCV] Consider relaxable call edges for PLT edges

For linker relaxation (D149526), a new edge kind (`CallRelaxable`) was
introduced. However, this new kind was not taken into account by
`PerGraphGOTAndPLTStubsBuilder_ELF_riscv`. This patch fixes this.

Reviewed By: StephenFan

Differential Revision: https://reviews.llvm.org/D150957

show more ...

[JITLink][RISCV] Implement linker relaxation

This patch is essentially an adaption of LLD's algorithm to JITLink.
Currently, only relaxing R_RISCV_CALL(_PLT) and R_RISCV_ALIGN is
implemented, other

[JITLink][RISCV] Implement linker relaxation

This patch is essentially an adaption of LLD's algorithm to JITLink.
Currently, only relaxing R_RISCV_CALL(_PLT) and R_RISCV_ALIGN is
implemented, other relocations can follow later.

From a high level, the algorithm works as follows. In the first phase
(relaxBlock), we iteratively try to relax all instructions that have a
R_RISCV_RELAX relocation:
- If, based on the current symbol values, an instruction sequence can be
relaxed (i.e., replaced by a shorter instruction), we record how many
bytes would be removed, the new instruction (Writes), and the new
relocation type (EdgeKinds).
- We keep track of the total number of bytes that got removed up to each
relocation in the RelocDeltas array. This is the cumulative sum of the
number of bytes removed for each relocation.
- Symbol values and sizes are updated based on the number of removed
bytes.
- If for any relocation, the current RelocDeltas value doesn't match the
one from the previous iteration, something changed and we need to run
another iteration as some symbols might now have different values.

In the second phase (finalizeBlockRelax), all code is moved based on
RelocDeltas, the relaxed instructions are rewritten using Writes, and
R_RISCV_ALIGN is handled (moving instructions to ensure alignment and
inserting the correct NOP-sequence if needed). Finally, edge kinds and
offsets are updated and all R_RISCV_RELAX and R_RISCV_ALIGN edges are
removed (they are not needed anymore for the fixup linking stage).

Linker relaxation is implemented as a pass and added to PreFixupPasses
in the default configuration on RISC-V.

Since linker relaxation removes instructions, the memory for blocks
should ideally be reallocated. However, I believe this is currently not
possible in JITLink. Therefore, relaxation directly modifies the memory
of blocks, reducing the number of instructions but not the size of
blocks. I'm not very familiar with JITLink's memory allocators so I
might be overlooking something here, though.

Note on testing: some of the tests rely on the debug output of
llvm-jitlink. The main reason for this is the verification of symbol
sizes (which may change due to relaxation). I don't believe this can be
done using jitlink-check checks alone.

Note that there is a slightly unrelated change that makes
Symbol::setOffset public to be able to update symbol offsets during
relaxation.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D149526

show more ...

[JITLink] Add target features to LinkGraph

This patch adds SubtargetFeatures to LinkGraph. Similar to Triple, some
targets might use this information while linking.

One example, and the reason this

[JITLink] Add target features to LinkGraph

This patch adds SubtargetFeatures to LinkGraph. Similar to Triple, some
targets might use this information while linking.

One example, and the reason this patch was written, is linker relaxation
on RISC-V: different relaxations are possible depending on if the C
extension is enabled.

Note that the features are stored as `std::vector<std::string>` to prevent a
public dependency on MC. There is still a private dependency to be able to
convert SubtargetFeatures to a vector.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D149522

show more ...

[JITLink][RISCV] Only generate PLT entries for external symbols

R_RISCV_CALL has been deprecated. [1] Both GCC and LLVM seem to not
generate it anymore and always use R_RISCV_CALL_PLT (even for call

[JITLink][RISCV] Only generate PLT entries for external symbols

R_RISCV_CALL has been deprecated. [1] Both GCC and LLVM seem to not
generate it anymore and always use R_RISCV_CALL_PLT (even for calls that
do not need a PLT entry). Generating PLT entries based on relocation
type is not recommended and a better heuristic is to only generate them
when the target symbol is preemptable [2]. This patch implements this by
only generating PLT entries for undefined symbols.

[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/340
[2] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/98

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D149525

show more ...

[JITLink][RISCV] Handle R_RISCV_CALL_PLT fixups

In the default link configuration, PLT stubs are created automatically
for R_RISCV_CALL_PLT relocations and the relocation itself is
transformed to R_

[JITLink][RISCV] Handle R_RISCV_CALL_PLT fixups

In the default link configuration, PLT stubs are created automatically
for R_RISCV_CALL_PLT relocations and the relocation itself is
transformed to R_RISCV_CALL (PerGraphGOTAndPLTStubsBuilder_ELF_riscv).
Only the latter is later handled when applying fixups and the former is
simply ignored.

This patch proposes to handle R_RISCV_CALL_PLT anyway when applying
fixups to support custom configurations that do not need automatic PLT
creation. An example of this is BOLT where PLT entries from the input
binary are reused (D147544).

Reviewed By: StephenFan

Differential Revision: https://reviews.llvm.org/D148238

show more ...

[JITLink][RISCV] ADD/SUB relocs: read value from working memory

The various ADD/SUB relocations work by reading the current value the
relocation points to, transforming it, and then writing it back

[JITLink][RISCV] ADD/SUB relocs: read value from working memory

The various ADD/SUB relocations work by reading the current value the
relocation points to, transforming it, and then writing it back to
memory. While the current implementation writes the value back to
working memory, it reads the current value from the execution address of
the relocation. This causes at least wrong results, but often crashes,
when the addresses of working memory are not equal to execution
addresses. This patch fixes this by reading the current value from
working memory.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D147693

show more ...

[JITLink] Drop const qualifier from argument to ELFLinkGraphBuilder's ctors (NFC)

These values are moved into the base class constructors, so the `const` doesn't make any sense. Turns out, I acciden

[JITLink] Drop const qualifier from argument to ELFLinkGraphBuilder's ctors (NFC)

These values are moved into the base class constructors, so the `const` doesn't make any sense. Turns out, I accidentally introduced it myself with 2ed91da0f1f3 and since than it spread by copy/paste.

show more ...

[JITLink][RISCV] Add R_RISCV_RVC_BRANCH and R_RISCV_RVC_JUMP

These are the compressed equivalents of the relocations R_RISCV_BRANCH
and R_RISCV_JAL with slightly more complex immediate handling.

Di

[JITLink][RISCV] Add R_RISCV_RVC_BRANCH and R_RISCV_RVC_JUMP

These are the compressed equivalents of the relocations R_RISCV_BRANCH
and R_RISCV_JAL with slightly more complex immediate handling.

Differential Revision: https://reviews.llvm.org/D140827

show more ...

[JITLink][RISCV] Homogenize immediate handling

Name the variables based on which part of the immediate value is
extracted, as it was already done for R_RISCV_JAL. This makes it
much easier to compar

[JITLink][RISCV] Homogenize immediate handling

Name the variables based on which part of the immediate value is
extracted, as it was already done for R_RISCV_JAL. This makes it
much easier to compare the logic with the spec.

Differential Revision: https://reviews.llvm.org/D140820

show more ...

[JITLink][RISCV] Improve R_RISCV_JAL

Only take the lower 12 bits of RawInstr.

Differential Revision: https://reviews.llvm.org/D140820

[JITLink][RISCV] Order EdgeKind_riscv the same way as relocations

There were basically four different orderings: one defined by the
relocations, one by the enum definition of EdgeKind_riscv, one for

[JITLink][RISCV] Order EdgeKind_riscv the same way as relocations

There were basically four different orderings: one defined by the
relocations, one by the enum definition of EdgeKind_riscv, one for
mapping the enum values to their names, and one when mapping the
relocations to edge kinds and finally processing them. Chose the
ordering defined by the relocations in the riscv-elf-psabi-doc as
the canonical one.

Differential Revision: https://reviews.llvm.org/D140802

show more ...

[JITLink][RISCV] Fix incorrectly use of uint32_t

[RISCV][JitLink] Propagate error from Expected<T> result during R_RISCV_PCREL_HI20 parsing

related issue: https://github.com/llvm/llvm-project/issues/59139

Differential Revision: https://reviews.ll

[RISCV][JitLink] Propagate error from Expected<T> result during R_RISCV_PCREL_HI20 parsing

related issue: https://github.com/llvm/llvm-project/issues/59139

Differential Revision: https://reviews.llvm.org/D138781

show more ...

[JITLink][RISCV] Add R_RISCV_LO12_S relocation support

Fixes: https://github.com/llvm/llvm-project/issues/58979

Reviewed By: Hahnfeld

Differential Revision: https://reviews.llvm.org/D138030