Currently the `tryFindDefinedOnIsec` takes in an `InputSection` and an
`offset` and is supposed to return the target symbol that is referenced
on that `InputSection` at the given offset.
However, it does not deal with the reloc `addend` and might return the
incorrect symbol.
Here we add support for handling the reloc's `addend`.
Summary:
The LTO pass currently supporting emitting LTO via the
`--plugin-opt=emit-llvm` option. However, there is a very similar option
called `--lto-emit-asm`. This patch just makes the usage more
consistent and more obvious that emitting LLVM-IR is supported.
This patch adds the documentation for a subset of scripting extensions
such as scripted process, scripted thread, operating system threads &
scritped thread plans to the lldb website.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
I've migrated uses of the old version of getValueProfDataFromInst to
the one that returns SmallVector<InstrProfValueData, 4>. This patch
removes the old version.
Summary:
These functions provide special-case implementations internal to the
OpenMP device runtime. This can potentially conflict with the symbols
pulled in from the actual GPU `libc`. This patch makes these weak, so in
the case that the GPU libc functions exist they will be overridden. This
should not impact performance in the average case because the old
`-mlink-builtin-bitcode` version does internalization, deleting weak,
and the new LTO path will resolve to the strong reference and then
internalize it.
When an undefined symbol is referenced from more than one file we were
reporting all undefined symbols as originating from just one of them.
This came up while working on
https://github.com/WebAssembly/tool-conventions/issues/158 where
undefined symbols in one object file were being reported as coming from
another.
When reference types are enabled clang will generate call_indirect
instructions that explicitly reference the global
`__indirect_function_table` symbol.
In this case the resulting global symbol was not being correctly marked
with explicit import name/module, resulting in the linker reporting
errors when it was referenced.
This issue was reported in
https://github.com/WebAssembly/tool-conventions/issues/158
The first object file whose EI_OSABI is not ELFOSABI_NONE is selected.
This is useful for some OSes to identify themselves. This achieves
similar effects to BFD emulations `ld.lld -m *_fbsd` but is more
lightweight.
Pull Request: https://github.com/llvm/llvm-project/pull/97144
An empty output section specified in the `SECTIONS` command (e.g.
`empty : { *(empty) }`) may be discarded. Due to phase ordering, we
might define `__start_empty`/`__stop_empty` symbols with incorrect
section indexes (usually benign, but could go out of bounds and cause
`readelf -s` to print `BAD`).
```
finalizeSections
addStartStopSymbols // __start_empty is defined
// __start_empty is added to .symtab
sortSections
adjustOutputSections // `empty` is discarded
writeSections
// __start_empty is Defined with an invalid section index
```
Loaders use `st_value` members of the start/stop symbols and expect no
"undefined symbol" linker error, but do not particularly care whether
the symbols are defined or undefined. Let's retain the associated empty
output section so that start/stop symbols will have correct section
indexes.
The approach allows us to remove `LinkerScript::isDiscarded`
(https://reviews.llvm.org/D114179). Also delete the
`findSection(".text")` special case from https://reviews.llvm.org/D46200,
which is unnecessary even before this patch (`elfHeader` would be fine
even with very large executables).
Note: we should be careful not to unnecessarily retain .ARM.exidx, which
would create an empty PT_ARM_EXIDX. ~40 tests would need to be updated.
---
An alternative is to discard the empty output section and keep the
start/stop symbols undefined. This approach needs more code and requires
`LinkerScript::isDiscarded` before we discard empty sections in
``adjustOutputSections`.
Pull Request: https://github.com/llvm/llvm-project/pull/96343
llvm-gsymutil eats a lot of RAM. On some large binaries, it causes OOM's on smaller hardware, consuming well over 64GB of RAM. This change frees line tables once we're done with them, and frees DWARFUnits's DIE's when we finish processing each DU, though they may get reconstituted if there are references from other DU's during processing. Once the conversion is complete, all DIE's are freed. The reduction in peak memory usage from these changes showed between 7-12% in my tests.
The double-checked locking around the creation & freeing of the data structures was tested on a 166 core system. I validated that it trivially malfunctioned without the locks (and with stupid reordering of the locks) and worked reliably with them.
---------
Co-authored-by: Kevin Frei <freik@meta.com>
and replace MCAssembler::Layout with a bool.
This mostly completes "[MC] Start merging MCAsmLayout into MCAssembler".
Note: BOLT used a dummy `MCAsmLayout` to call `getSymbolOffset`, which
is technically not supported. There is some discussion in
https://reviews.llvm.org/D154604 .
The revert f80a4072ced41b52363c63df28fea9a649f7f89e is incorrect and
actually broke bots.
This isn't used in tree, and thus I don't know what the expectations for
its behavior really are. The original usage of this feature has been replaced
by parseNormalizedArchString.
The current implementation for `system_clock()` returns the CPU time
instead of elapsed wallclock time. This PR fixes the issue and makes
`system_clock()` correctly return elapsed time.
9d0754ada5dbbc0c009bcc2f7824488419cc5530 dropped MC support required for
optimal macro-fusion alignment in BOLT. Remove the support in BOLT as
performance measurements with large binaries didn't show a significant
improvement.
Test Plan:
macro-fusion alignment was never upstreamed, so no upstream tests are
affected.
"C4858 This function constructs an object wrapped by a smart pointer and has no other effects; it is not useful to call this function and discard the return value."
This patch refactors code related to `LoopFuseSiblingOp` transform in
attempt to reduce duplicate common code. The aim is to refactor as much
as possible to a functions on `LoopLikeOpInterface`s, but this is still
a work in progress. A full refactor will require more additions to the
`LoopLikeOpInterface`.
In addition, `scf.parallel` fusion support has been added.
With this PR I am trying to address:
https://github.com/llvm/llvm-project/issues/63230.
What changed:
- While merging identical blocks, don't add a block argument if it is
"identical" to another block argument. I.e., if the two block arguments
refer to the same `Value`. The operations operands in the block will
point to the argument we already inserted
- After merged the blocks, get rid of "unnecessary" arguments. I.e., if
all the predecessors pass the same block argument, there is no need to
pass it as an argument.
- This last simplification clashed with
`BufferDeallocationSimplification`. The reason, I think, is that the two
simplifications are clashing. I.e., `BufferDeallocationSimplification`
contains an analysis based on the block structure. If we simplify the
block structure (by merging and/or dropping block arguments) the
analysis is invalid . The solution I found is to do a more prudent
simplification when running that pass.
**Note**: many tests are still not passing. But I wanted to submit the
code before changing all the tests (and probably adding a couple), so
that we can agree in principle on the algorithm/design.
This reverts commit c72cb2766cec0ac519a051780ae5aed42485e012.
The patch was not reviewed, and this assertion guards against incorrect
values for symbols if the linker decides to modify the layout as it
happens on some platforms. getSymbolOffset() is used for code size
estimation, among others.
Reverting for now, until we get proper code review and undersatnding of
the implications.
This is another attempt at a change that Jean made to Phabricator in
https://reviews.llvm.org/D116934. That attempt ran into problems with
building on Windows.
This change improves the messages that are produced when running into
invalid arguments during constant folding.
Note that the original attempt at implementing this contained additional
code in .../llvm-project/flang/test/Evaluate/folding04.f90:
```
!WARN: warning: argument 'x' must be strictly positive
real(8), parameter :: nan_r8_dlog1 = dlog(-0.1_8)
TEST_ISNAN(nan_r8_dlog1)
```
For reasons I don't understand, this additional code caused the Windows
build to fail. So this new version of the update does not contain that
code.
When performing cross in-tree builds, we need native versions of various
tools, we cannot assume the cross builds that are part of the current
build are executable. LLVM provides the setup_host_tool function to
handle this, either picking up versions of tools from
LLVM_NATIVE_TOOL_DIR, or implicitly building native versions as needed.
Use it for libclc too.
LLVM's setup_host_tool function assumes the project is LLVM, so this
also needs libclc's project() to be conditional on it being built
standalone. Luckily, the only change this needs is using
CMAKE_CURRENT_SOURCE_DIR instead of PROJECT_SOURCE_DIR.
PR #96165 broke code similar to this test, and was subsequently
reverted. Add a test-case, to ensure the problem won't reoccur.
This error is potentially related to issues #59292 and #59966.
atomicrmw fmax/fmin perform the same operation as llvm.maxnum/minnum
which return the other operand if one operand is nan. This means that,
in the presence of nan arguments, +/- inf is not an identity for these
operations but nan is (at least if you don't care about nan payloads).
https://github.com/llvm/llvm-project/pull/83381 introduced a call
to PHINode::isComplete() in Mem2Reg, which is O(n^2) in the number
of predecessors, resulting in pathological compile-time regressions
for cases with many predecessors.
Remove the isComplete() check and instead cache the attribute
lookup, to only perform it once per function. Actually setting
the FMF flag is cheap.
