Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
283dca56 |
| 13-Jan-2025 |
Daniel Paoliello <danpao@microsoft.com> |
Reapply "[aarch64][win] Add support for import call optimization (equivalent to MSVC /d2ImportCallOptimization) (#121516)" (#122777)
This reverts commit 2f7ade4b5e399962e18f5f9a0ab0b7335deece51.
Fi
Reapply "[aarch64][win] Add support for import call optimization (equivalent to MSVC /d2ImportCallOptimization) (#121516)" (#122777)
This reverts commit 2f7ade4b5e399962e18f5f9a0ab0b7335deece51.
Fix is available in #122762
show more ...
|
#
2f7ade4b |
| 13-Jan-2025 |
Kirill Stoimenov <kstoimenov@google.com> |
Revert "[aarch64][win] Add support for import call optimization (equivalent to MSVC /d2ImportCallOptimization) (#121516)"
Breaks sanitizer build: https://lab.llvm.org/buildbot/#/builders/52/builds/5
Revert "[aarch64][win] Add support for import call optimization (equivalent to MSVC /d2ImportCallOptimization) (#121516)"
Breaks sanitizer build: https://lab.llvm.org/buildbot/#/builders/52/builds/5179
This reverts commits: 5ee0a71df919a328c714e25f0935c21e586cc18b d997a722c194feec5f3a94dec5acdce59ac5e55b
show more ...
|
#
5ee0a71d |
| 12-Jan-2025 |
Daniel Paoliello <danpao@microsoft.com> |
[aarch64][win] Add support for import call optimization (equivalent to MSVC /d2ImportCallOptimization) (#121516)
This change implements import call optimization for AArch64 Windows (equivalent to th
[aarch64][win] Add support for import call optimization (equivalent to MSVC /d2ImportCallOptimization) (#121516)
This change implements import call optimization for AArch64 Windows (equivalent to the undocumented MSVC `/d2ImportCallOptimization` flag).
Import call optimization adds additional data to the binary which can be used by the Windows kernel loader to rewrite indirect calls to imported functions as direct calls. It uses the same [Dynamic Value Relocation Table mechanism that was leveraged on x64 to implement `/d2GuardRetpoline`](https://techcommunity.microsoft.com/blog/windowsosplatform/mitigating-spectre-variant-2-with-retpoline-on-windows/295618).
The change to the obj file is to add a new `.impcall` section with the following layout: ```cpp // Per section that contains calls to imported functions: // uint32_t SectionSize: Size in bytes for information in this section. // uint32_t Section Number // Per call to imported function in section: // uint32_t Kind: the kind of imported function. // uint32_t BranchOffset: the offset of the branch instruction in its // parent section. // uint32_t TargetSymbolId: the symbol id of the called function. ```
NOTE: If the import call optimization feature is enabled, then the `.impcall` section must be emitted, even if there are no calls to imported functions.
The implementation is split across a few parts of LLVM: * During AArch64 instruction selection, the `GlobalValue` for each call to a global is recorded into the Extra Information for that node. * During lowering to machine instructions, the called global value for each call is noted in its containing `MachineFunction`. * During AArch64 asm printing, if the import call optimization feature is enabled: - A (new) `.impcall` directive is emitted for each call to an imported function. - The `.impcall` section is emitted with its magic header (but is not filled in). * During COFF object writing, the `.impcall` section is filled in based on each `.impcall` directive that were encountered.
The `.impcall` section can only be filled in when we are writing the COFF object as it requires the actual section numbers, which are only assigned at that point (i.e., they don't exist during asm printing).
I had tried to avoid using the Extra Information during instruction selection and instead implement this either purely during asm printing or in a `MachineFunctionPass` (as suggested in [on the forums](https://discourse.llvm.org/t/design-gathering-locations-of-instructions-to-emit-into-a-section/83729/3)) but this was not possible due to how loading and calling an imported function works on AArch64. Specifically, they are emitted as `ADRP` + `LDR` (to load the symbol) then a `BR` (to do the call), so at the point when we have machine instructions, we would have to work backwards through the instructions to discover what is being called. An initial prototype did work by inspecting instructions; however, it didn't correctly handle the case where the same function was called twice in a row, which caused LLVM to elide the `ADRP` + `LDR` and reuse the previously loaded address. Worse than that, sometimes for the double-call case LLVM decided to spill the loaded address to the stack and then reload it before making the second call. So, instead of trying to implement logic to discover where the value in a register came from, I instead recorded the symbol being called at the last place where it was easy to do: instruction selection.
show more ...
|
Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
bb3f5e1f |
| 14-Nov-2024 |
Matin Raayai <30674652+matinraayai@users.noreply.github.com> |
Overhaul the TargetMachine and LLVMTargetMachine Classes (#111234)
Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/
Overhaul the TargetMachine and LLVMTargetMachine Classes (#111234)
Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/117907.html,
https://reviews.llvm.org/D38482, https://reviews.llvm.org/D38489, this
PR attempts to overhaul the `TargetMachine` and `LLVMTargetMachine`
interface classes. More specifically:
1. Makes `TargetMachine` the only class implemented under
`TargetMachine.h` in the `Target` library.
2. `TargetMachine` contains target-specific interface functions that
relate to IR/CodeGen/MC constructs, whereas before (at least on paper)
it was supposed to have only IR/MC constructs. Any Target that doesn't
want to use the independent code generator simply does not implement
them, and returns either `false` or `nullptr`.
3. Renames `LLVMTargetMachine` to `CodeGenCommonTMImpl`. This renaming
aims to make the purpose of `LLVMTargetMachine` clearer. Its interface
was moved under the CodeGen library, to further emphasis its usage in
Targets that use CodeGen directly.
4. Makes `TargetMachine` the only interface used across LLVM and its
projects. With these changes, `CodeGenCommonTMImpl` is simply a set of
shared function implementations of `TargetMachine`, and CodeGen users
don't need to static cast to `LLVMTargetMachine` every time they need a
CodeGen-specific feature of the `TargetMachine`.
5. More importantly, does not change any requirements regarding library
linking.
cc @arsenm @aeubanks
show more ...
|
Revision tags: llvmorg-19.1.3 |
|
#
b5cc222d |
| 16-Oct-2024 |
Akshat Oke <Akshat.Oke@amd.com> |
[MIR] Fix vreg flag vector memory leak (#112479)
A fix-it patch for dbfca24 #110228.
No need for a container. This allows 8 flags for a register.
The virtual register flags vector had a memory
[MIR] Fix vreg flag vector memory leak (#112479)
A fix-it patch for dbfca24 #110228.
No need for a container. This allows 8 flags for a register.
The virtual register flags vector had a memory leak because the vector's
memory is not freed.
The `BumpPtrAllocator` handles the deallocation and missed calling the
`std::vector<uint8_t> Flags` destructor.
show more ...
|
Revision tags: llvmorg-19.1.2 |
|
#
3dba5d85 |
| 14-Oct-2024 |
Akshat Oke <76596238+optimisan@users.noreply.github.com> |
[MIR] Add missing noteNewVirtualRegister callbacks (#111634)
The delegates' callback isn't invoked on parsing new virtual registers.
There are two places in the serialization where new virtual regi
[MIR] Add missing noteNewVirtualRegister callbacks (#111634)
The delegates' callback isn't invoked on parsing new virtual registers.
There are two places in the serialization where new virtual registers can be discovered: in register infos and in instructions.
show more ...
|
#
dbfca24b |
| 14-Oct-2024 |
Akshat Oke <76596238+optimisan@users.noreply.github.com> |
[MIR] Serialize virtual register flags (#110228)
[MIR] Serialize virtual register flags
This introduces target-specific vreg flag serialization. Flags are represented as `uint8_t` and the `TargetRe
[MIR] Serialize virtual register flags (#110228)
[MIR] Serialize virtual register flags
This introduces target-specific vreg flag serialization. Flags are represented as `uint8_t` and the `TargetRegisterInfo` override provides methods `getVRegFlagValue` to deserialize and `getVRegFlagsOfReg` to serialize.
show more ...
|
#
d826b0c9 |
| 04-Oct-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[LLVM] Add HasFakeUses to MachineFunction (#110097)
Following the addition of the llvm.fake.use intrinsic and corresponding
MIR instruction, two further changes are planned: to add an
-fextend-lif
[LLVM] Add HasFakeUses to MachineFunction (#110097)
Following the addition of the llvm.fake.use intrinsic and corresponding
MIR instruction, two further changes are planned: to add an
-fextend-lifetimes flag to Clang that emits these intrinsics, and to
have -Og enable this flag by default. Currently, some logic for handling
fake uses is gated by the optdebug attribute, which is intended to be
switched on by -fextend-lifetimes (and by extension -Og later on).
However, the decision was made that a general optdebug attribute should
be incompatible with other opt_ attributes (e.g. optsize, optnone),
since they all express different intents for how to optimize the
program. We would still like to allow -fextend-lifetimes with optsize
however (i.e. -Os -fextend-lifetimes should be legal), since it may be a
useful configuration and there is no technical reason to not allow it.
This patch resolves this by tracking MachineFunctions that have fake
uses, allowing us to run passes that interact with them and skip passes
that clash with them.
show more ...
|
Revision tags: llvmorg-19.1.1 |
|
#
7b7747dc |
| 26-Sep-2024 |
Rahman Lavaee <rahmanl@google.com> |
Reapply "Deprecate the `-fbasic-block-sections=labels` option." (#110039)
This reapplies commit 1911a50fae8a441b445eb835b98950710d28fc88 with a
minor fix in lld/ELF/LTO.cpp which sets Options.BBAdd
Reapply "Deprecate the `-fbasic-block-sections=labels` option." (#110039)
This reapplies commit 1911a50fae8a441b445eb835b98950710d28fc88 with a
minor fix in lld/ELF/LTO.cpp which sets Options.BBAddrMap when
`--lto-basic-block-sections=labels` is passed.
show more ...
|
#
639a0afa |
| 25-Sep-2024 |
Kazu Hirata <kazu@google.com> |
Revert "Deprecate the `-fbasic-block-sections=labels` option. (#107494)"
This reverts commit 1911a50fae8a441b445eb835b98950710d28fc88.
Several bots are failing:
https://lab.llvm.org/buildbot/#/bui
Revert "Deprecate the `-fbasic-block-sections=labels` option. (#107494)"
This reverts commit 1911a50fae8a441b445eb835b98950710d28fc88.
Several bots are failing:
https://lab.llvm.org/buildbot/#/builders/190/builds/6519 https://lab.llvm.org/buildbot/#/builders/3/builds/5248 https://lab.llvm.org/buildbot/#/builders/18/builds/4463
show more ...
|
#
1911a50f |
| 25-Sep-2024 |
Rahman Lavaee <rahmanl@google.com> |
Deprecate the `-fbasic-block-sections=labels` option. (#107494)
This feature is supported via the newer option
`-fbasic-block-address-map`. Using the old option still works by
delegating to the ne
Deprecate the `-fbasic-block-sections=labels` option. (#107494)
This feature is supported via the newer option
`-fbasic-block-address-map`. Using the old option still works by
delegating to the newer option, while a warning is printed to show
deprecation.
show more ...
|
#
d853adee |
| 25-Sep-2024 |
Dominik Montada <dominik.montada@arm.com> |
[MIR] Fix return value when computed properties conflict with given prop (#109923)
This fixes a test failure when expensive checks are enabled. Use the
correct return value when computing machine f
[MIR] Fix return value when computed properties conflict with given prop (#109923)
This fixes a test failure when expensive checks are enabled. Use the
correct return value when computing machine function properties resulted
in an error (e.g. when conflicting with explicitly set values).
Without this, the machine verifier would crash even in the presence of
parsing errors which should have gently terminated execution.
show more ...
|
#
71ca9fcb |
| 24-Sep-2024 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
llvm-reduce: Don't print verifier failed machine functions (#109673)
This produces far too much terminal output, particularly for the
instruction reduction. Since it doesn't consider the liveness o
llvm-reduce: Don't print verifier failed machine functions (#109673)
This produces far too much terminal output, particularly for the
instruction reduction. Since it doesn't consider the liveness of of
the instructions it's deleting, it produces quite a lot of verifier
errors.
show more ...
|
#
8ba334bc |
| 24-Sep-2024 |
Dominik Montada <dominik.montada@arm.com> |
[MIR] Allow overriding isSSA, noPhis, noVRegs in MIR input (#108546)
Allow setting the computed properties IsSSA, NoPHIs, NoVRegs for MIR
functions in MIR input. The default value is still the comp
[MIR] Allow overriding isSSA, noPhis, noVRegs in MIR input (#108546)
Allow setting the computed properties IsSSA, NoPHIs, NoVRegs for MIR
functions in MIR input. The default value is still the computed value.
If the property is set to false, the computed result is ignored. Conflicting
values (e.g. setting IsSSA where the input MIR is clearly not SSA) lead to
an error.
Closes #37787
show more ...
|
#
e03f4271 |
| 19-Sep-2024 |
Jay Foad <jay.foad@amd.com> |
[LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133)
It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all oc
[LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133)
It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.
show more ...
|
Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
cf2f32c9 |
| 01-May-2024 |
David Tellenbach <dtellenbach@apple.com> |
[MIR] Serialize MachineFrameInfo::isCalleeSavedInfoValid() (#90561)
In case of functions without a stack frame no "stack" field is
serialized into MIR which leads to isCalleeSavedInfoValid being fa
[MIR] Serialize MachineFrameInfo::isCalleeSavedInfoValid() (#90561)
In case of functions without a stack frame no "stack" field is
serialized into MIR which leads to isCalleeSavedInfoValid being false
when reading a MIR file back in. To fix this we should serialize
MachineFrameInfo::isCalleeSavedInfoValid() into MIR.
show more ...
|
#
6ea0c0a2 |
| 30-Apr-2024 |
paperchalice <liujunchang97@outlook.com> |
[NewPM][CodeGen] Add `MachineFunctionAnalysis` (#88610)
In new pass system, `MachineFunction` could be an analysis result again,
machine module pass can now fetch them from analysis manager.
`Mach
[NewPM][CodeGen] Add `MachineFunctionAnalysis` (#88610)
In new pass system, `MachineFunction` could be an analysis result again,
machine module pass can now fetch them from analysis manager.
`MachineModuleInfo` no longer owns them.
Remove `FreeMachineFunctionPass`, replaced by
`InvalidateAnalysisPass<MachineFunctionAnalysis>`.
Now `FreeMachineFunction` is replaced by
`InvalidateAnalysisPass<MachineFunctionAnalysis>`, the workaround in
`MachineFunctionPassManager` is no longer needed, there is no difference
between `unittests/MIR/PassBuilderCallbacksTest.cpp` and
`unittests/IR/PassBuilderCallbacksTest.cpp`.
show more ...
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3 |
|
#
212b1a84 |
| 02-Apr-2024 |
Prabhuk <prabhukr@google.com> |
[CallSiteInfo][NFC] CallSiteInfo -> CallSiteInfo.ArgRegPairs (#86842)
CallSiteInfo is originally used only for argument - register pairs. Make
it struct, in which we can store additional data for c
[CallSiteInfo][NFC] CallSiteInfo -> CallSiteInfo.ArgRegPairs (#86842)
CallSiteInfo is originally used only for argument - register pairs. Make
it struct, in which we can store additional data for call sites.
Also, the variables/methods used for CallSiteInfo are named for its
original use case, e.g., CallFwdRegsInfo. Refactor these for the
upcoming
use, e.g. addCallArgsForwardingRegs() -> addCallSiteInfo().
An upcoming patch will add type ids for indirect calls to propogate them
from
middle-end to the back-end. The type ids will be then used to emit the
call
graph section.
Original RFC:
https://lists.llvm.org/pipermail/llvm-dev/2021-June/151044.html
Updated RFC:
https://lists.llvm.org/pipermail/llvm-dev/2021-July/151739.html
Differential Revision: https://reviews.llvm.org/D107109?id=362888
Co-authored-by: Necip Fazil Yildiran <necip@google.com>
show more ...
|
Revision tags: llvmorg-18.1.2 |
|
#
63a5dc4a |
| 11-Mar-2024 |
Jay Foad <jay.foad@amd.com> |
[CodeGen] Do not pass MF into MachineRegisterInfo methods. NFC. (#84770)
MachineRegisterInfo already knows the MF so there is no need to pass it
in as an argument.
|
Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2 |
|
#
1b33b3f2 |
| 04-Feb-2024 |
Kazu Hirata <kazu@google.com> |
[MIRParser] Simplify a string comparison (NFC)
|
Revision tags: llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3 |
|
#
6e8013a1 |
| 14-Oct-2023 |
Kazu Hirata <kazu@google.com> |
[llvm] Stop including llvm/ADT/StringMap.h (NFC)
These source files do not use StringMap.
|
Revision tags: llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
fbb241c5 |
| 29-May-2023 |
Wang, Xin10 <xin10.wang@intel.com> |
use ref to avoid copy in range for-loop
Use big obj copy in range for-loop will call copy constructor every time, which can be avoided by use ref instead.
Reviewed By: skan
Differential Revision:
use ref to avoid copy in range for-loop
Use big obj copy in range for-loop will call copy constructor every time, which can be avoided by use ref instead.
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D150024
show more ...
|
Revision tags: llvmorg-16.0.4, llvmorg-16.0.3 |
|
#
33b69b97 |
| 01-May-2023 |
Felipe de Azevedo Piovezan <fpiovezan@apple.com> |
[YamlMF] Serialize EntryValueObjects
This commit implements the serialization and deserialization of the Machine Function's EntryValueObjects.
Depends on D149879, D149778
Differential Revision: ht
[YamlMF] Serialize EntryValueObjects
This commit implements the serialization and deserialization of the Machine Function's EntryValueObjects.
Depends on D149879, D149778
Differential Revision: https://reviews.llvm.org/D149880
show more ...
|
#
ae39de91 |
| 04-May-2023 |
Felipe de Azevedo Piovezan <fpiovezan@apple.com> |
[MIRParser][nfc] Factor out code parsing debug MD nodes
This commit splits a function that both parses MD nodes from YAML into DI{Expr,Loc,Variable} objects AND adds an entry to the MF variable tabl
[MIRParser][nfc] Factor out code parsing debug MD nodes
This commit splits a function that both parses MD nodes from YAML into DI{Expr,Loc,Variable} objects AND adds an entry to the MF variable table, so that each of those jobs is done separately.
It will enable subsequent patches to reuse the MD node parsing code.
Differential Revision: https://reviews.llvm.org/D149870
show more ...
|
Revision tags: llvmorg-16.0.2 |
|
#
267708f9 |
| 10-Apr-2023 |
wangpc <pc.wang@linux.alibaba.com> |
[MachineOutliner] Add IsOutlined to MachineFunction
We add a field `IsOutlined` to indicate whether a MachineFunction is outlined and set it true for outlined functions in MachineOutliner.
Reviewed
[MachineOutliner] Add IsOutlined to MachineFunction
We add a field `IsOutlined` to indicate whether a MachineFunction is outlined and set it true for outlined functions in MachineOutliner.
Reviewed By: paquette
Differential Revision: https://reviews.llvm.org/D146191
show more ...
|