Revision tags: llvmorg-21-init |
|
#
44c9e46f |
| 27-Jan-2025 |
Shubham Sandeep Rastogi <srastogi22@apple.com> |
[InstrRef] Fix mismatch between LiveDebugValues and salvageCopySSA (#124233)
The LiveDebugValues pass and the instruction selector (which calls
salvageCopySSA) need to be consistent on what they co
[InstrRef] Fix mismatch between LiveDebugValues and salvageCopySSA (#124233)
The LiveDebugValues pass and the instruction selector (which calls
salvageCopySSA) need to be consistent on what they consider a copy
instruction. With https://github.com/llvm/llvm-project/pull/75184, the
definition of what a copy instruction is was narrowed for AArch64 to
exclude a w->x ORR and treat it as a zero-extend rather than a copy
However, to make sure LiveDebugValues still treats a w->x ORR as a copy,
the new function, isCopyLikeInstr was created. We need to make sure that
salvageCopySSA also calls that function.
This patch addresses this mismatch.
show more ...
|
#
6292a808 |
| 24-Jan-2025 |
Jeremy Morse <jeremy.morse@sony.com> |
[NFC][DebugInfo] Use iterator-flavour getFirstNonPHI at many call-sites (#123737)
As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNo
[NFC][DebugInfo] Use iterator-flavour getFirstNonPHI at many call-sites (#123737)
As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNonPHI and similar feed into
instruction insertion positions. Call-sites where that's necessary were
updated a year ago; but to ensure some type safety however, we'd like to
have all calls to getFirstNonPHI use the iterator-returning version.
This patch changes a bunch of call-sites calling getFirstNonPHI to use
getFirstNonPHIIt, which returns an iterator. All these call sites are
where it's obviously safe to fetch the iterator then dereference it. A
follow-up patch will contain less-obviously-safe changes.
We'll eventually deprecate and remove the instruction-pointer
getFirstNonPHI, but not before adding concise documentation of what
considerations are needed (very few).
---------
Co-authored-by: Stephen Tozer <Melamoto@gmail.com>
show more ...
|
#
de209fa1 |
| 23-Jan-2025 |
Mingming Liu <mingmingl@google.com> |
[CodeGen] Introduce Static Data Splitter pass (#122183)
https://discourse.llvm.org/t/rfc-profile-guided-static-data-partitioning/83744 proposes to partition static data sections.
This patch introdu
[CodeGen] Introduce Static Data Splitter pass (#122183)
https://discourse.llvm.org/t/rfc-profile-guided-static-data-partitioning/83744 proposes to partition static data sections.
This patch introduces a codegen pass. This patch produces jump table hotness in the in-memory states (machine jump table info and entries). Target-lowering and asm-printer consume the states and produce `.hot` section suffix. The follow up PR https://github.com/llvm/llvm-project/pull/122215 implements such changes.
---------
Co-authored-by: Ellis Hoag <ellis.sparky.hoag@gmail.com>
show more ...
|
Revision tags: llvmorg-19.1.7 |
|
#
19032bfe |
| 13-Jan-2025 |
Daniel Paoliello <danpao@microsoft.com> |
[aarch64][win] Update Called Globals info when updating Call Site info (#122762)
Fixes the "use after poison" issue introduced by #121516 (see <https://github.com/llvm/llvm-project/pull/121516#issue
[aarch64][win] Update Called Globals info when updating Call Site info (#122762)
Fixes the "use after poison" issue introduced by #121516 (see <https://github.com/llvm/llvm-project/pull/121516#issuecomment-2585912395>).
The root cause of this issue is that #121516 introduced "Called Global" information for call instructions modeling how "Call Site" info is stored in the machine function, HOWEVER it didn't copy the copy/move/erase operations for call site information.
The fix is to rename and update the existing copy/move/erase functions so they also take care of Called Global info.
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
61f99a1c |
| 16-Dec-2024 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
RegAlloc: Do not fatal error if there are no registers in the alloc order (#119640)
Try to use DiagnosticInfo if every register in the class is reserved by forcing assignment to a reserved register.
RegAlloc: Do not fatal error if there are no registers in the alloc order (#119640)
Try to use DiagnosticInfo if every register in the class is reserved by forcing assignment to a reserved register. Also reduces the number of redundant errors emitted, particularly with fast.
This is still broken in the case of undef uses. There are additional complications in greedy and fast, so leave it for a separate fix.
show more ...
|
Revision tags: 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 ...
|
#
735ab61a |
| 13-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Remove unused includes (NFC) (#115996)
Identified with misc-include-cleaner.
|
#
3b1b1271 |
| 07-Nov-2024 |
Andrei Safronov <andrei.safronov@espressif.com> |
[Xtensa] Implement support for the BranchRelaxation. (#113450)
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2 |
|
#
b01be72a |
| 04-Oct-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[NFC][CodeGen] Remove unused HasFakeUses MachineFunctionProperty
A previous commit d826b0c9 accidentally added a new MachineFunctionProperty, HasFakeUses, that was unused by the commit (and results
[NFC][CodeGen] Remove unused HasFakeUses MachineFunctionProperty
A previous commit d826b0c9 accidentally added a new MachineFunctionProperty, HasFakeUses, that was unused by the commit (and results in an uncovered-switch warning, which was fixed by a separate followup 1811e872); this patch removes that enum value.
show more ...
|
#
1811e872 |
| 04-Oct-2024 |
Jie Fu <jiefu@tencent.com> |
[CodeGen] Fix enumeration value 'HasFakeUses' not handled in switch (NFC)
llvm-project/llvm/lib/CodeGen/MachineFunction.cpp:95:10: error: enumeration value 'HasFakeUses' not handled in switch [-Werr
[CodeGen] Fix enumeration value 'HasFakeUses' not handled in switch (NFC)
llvm-project/llvm/lib/CodeGen/MachineFunction.cpp:95:10: error: enumeration value 'HasFakeUses' not handled in switch [-Werror,-Wswitch] switch(Prop) { ^~~~ 1 error generated.
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 ...
|
Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3 |
|
#
d871b2e0 |
| 06-Aug-2024 |
Alexis Engelke <engelke@in.tum.de> |
[CodeGen] Use optimized domtree for MachineFunction (#102107)
The dominator tree gained an optimization to use block numbers instead
of a DenseMap to store blocks. Given that machine basic blocks a
[CodeGen] Use optimized domtree for MachineFunction (#102107)
The dominator tree gained an optimization to use block numbers instead
of a DenseMap to store blocks. Given that machine basic blocks already
have numbers, expose these via appropriate GraphTraits. For debugging,
block number epochs are added to MachineFunction -- this greatly helps
in finding uses of block numbers after RenumberBlocks().
In a few cases where dominator trees are preserved across renumberings,
the dominator tree is updated to use the new numbers.
show more ...
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1 |
|
#
63e16478 |
| 26-Jul-2024 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
CodeGen: Remove MachineModuleInfo reference from MachineFunction (#100357)
This avoids another unserializable field. Move the DbgInfoAvailable field into the AsmPrinter, which is only really a cache
CodeGen: Remove MachineModuleInfo reference from MachineFunction (#100357)
This avoids another unserializable field. Move the DbgInfoAvailable field into the AsmPrinter, which is only really a cache/convenience bit for checking a direct IR module metadata check.
show more ...
|
#
6f83a031 |
| 26-Jul-2024 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
CodeGen: Move current call site out of MachineModuleInfo (#100369)
I do not know understand what this is for, but it's only used in SelectionDAGBuilder, so move it to FunctionLoweringInfo like other
CodeGen: Move current call site out of MachineModuleInfo (#100369)
I do not know understand what this is for, but it's only used in SelectionDAGBuilder, so move it to FunctionLoweringInfo like other function scope DAG builder state. The intrinsics are not documented in the LangRef or Intrinsics.td.
This removes the last piece of codegen state from MachineModuleInfo.
show more ...
|
Revision tags: llvmorg-20-init |
|
#
9df71d76 |
| 28-Jun-2024 |
Nikita Popov <npopov@redhat.com> |
[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)
Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, re
[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)
Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7 |
|
#
9fe7aef1 |
| 29-May-2024 |
aengelke <engelke@in.tum.de> |
[CodeGen] Don't check attrs for stack realign (#92564)
shouldRealignStack/canRealignStack are repeatedly called in PEI (through
hasStackRealignment). Checking function attributes is expensive, so
[CodeGen] Don't check attrs for stack realign (#92564)
shouldRealignStack/canRealignStack are repeatedly called in PEI (through
hasStackRealignment). Checking function attributes is expensive, so
cache this data in the MachineFrameInfo, which had most data already.
This slightly changes the semantics of `MachineFrameInfo::ForcedRealign`
to be also true when the `stackrealign` attribute is set.
show more ...
|
Revision tags: llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
cf328ff9 |
| 24-Apr-2024 |
Pierre van Houtryve <pierre.vanhoutryve@amd.com> |
[IR] Memory Model Relaxation Annotations (#78569)
Implements the core/target-agnostic components of Memory Model
Relaxation Annotations.
RFC:
https://discourse.llvm.org/t/rfc-mmras-memory-model
[IR] Memory Model Relaxation Annotations (#78569)
Implements the core/target-agnostic components of Memory Model
Relaxation Annotations.
RFC:
https://discourse.llvm.org/t/rfc-mmras-memory-model-relaxation-annotations/76361/5
show more ...
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2 |
|
#
601e102b |
| 17-Mar-2024 |
David Green <david.green@arm.com> |
[CodeGen] Use LocationSize for MMO getSize (#84751)
This is part of #70452 that changes the type used for the external
interface of MMO to LocationSize as opposed to uint64_t. This means the
const
[CodeGen] Use LocationSize for MMO getSize (#84751)
This is part of #70452 that changes the type used for the external
interface of MMO to LocationSize as opposed to uint64_t. This means the
constructors take LocationSize, and convert ~UINT64_C(0) to
LocationSize::beforeOrAfter(). The getSize methods return a
LocationSize.
This allows us to be more precise with unknown sizes, not accidentally
treating them as unsigned values, and in the future should allow us to
add proper scalable vector support but none of that is included in this
patch. It should mostly be an NFC.
Global ISel is still expected to use the underlying LLT as it needs, and
are not expected to see unknown sizes for generic operations. Most of
the changes are hopefully fairly mechanical, adding a lot of getValue()
calls and protecting them with hasValue() where needed.
show more ...
|
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 |
|
#
acec6419 |
| 02-Feb-2024 |
Rahman Lavaee <rahmanl@google.com> |
[SHT_LLVM_BB_ADDR_MAP] Allow basic-block-sections and labels be used together by decoupling the handling of the two features. (#74128)
Today `-split-machine-functions` and `-fbasic-block-sections={a
[SHT_LLVM_BB_ADDR_MAP] Allow basic-block-sections and labels be used together by decoupling the handling of the two features. (#74128)
Today `-split-machine-functions` and `-fbasic-block-sections={all,list}`
cannot be combined with `-basic-block-sections=labels` (the labels
option will be ignored).
The inconsistency comes from the way basic block address map -- the
underlying mechanism for basic block labels -- encodes basic block
addresses
(https://lists.llvm.org/pipermail/llvm-dev/2020-July/143512.html).
Specifically, basic block offsets are computed relative to the function
begin symbol. This relies on functions being contiguous which is not the
case for MFS and basic block section binaries. This means Propeller
cannot use binary profiles collected from these binaries, which limits
the applicability of Propeller for iterative optimization.
To make the `SHT_LLVM_BB_ADDR_MAP` feature work with basic block section
binaries, we propose modifying the encoding of this section as follows.
First let us review the current encoding which emits the address of each
function and its number of basic blocks, followed by basic block entries
for each basic block.
| | |
|--|--|
| Address of the function | Function Address |
| Number of basic blocks in this function | NumBlocks |
| BB entry 1
| BB entry 2
| ...
| BB entry #NumBlocks
To make this work for basic block sections, we treat each basic block
section similar to a function, except that basic block sections of the
same function must be encapsulated in the same structure so we can map
all of them to their single function.
We modify the encoding to first emit the number of basic block sections
(BB ranges) in the function. Then we emit the address map of each basic
block section section as before: the base address of the section, its
number of blocks, and BB entries for its basic block. The first section
in the BB address map is always the function entry section.
| | |
|--|--|
| Number of sections for this function | NumBBRanges |
| Section 1 begin address | BaseAddress[1] |
| Number of basic blocks in section 1 | NumBlocks[1] |
| BB entries for Section 1
|..................|
| Section #NumBBRanges begin address | BaseAddress[NumBBRanges] |
| Number of basic blocks in section #NumBBRanges |
NumBlocks[NumBBRanges] |
| BB entries for Section #NumBBRanges
The encoding of basic block entries remains as before with the minor
change that each basic block offset is now computed relative to the
begin symbol of its containing BB section.
This patch adds a new boolean codegen option `-basic-block-address-map`.
Correspondingly, the front-end flag `-fbasic-block-address-map` and LLD
flag `--lto-basic-block-address-map` are introduced.
Analogously, we add a new TargetOption field `BBAddrMap`. This means BB
address maps are either generated for all functions in the compiling
unit, or for none (depending on `TargetOptions::BBAddrMap`).
This patch keeps the functionality of the old
`-fbasic-block-sections=labels` option but does not remove it. A
subsequent patch will remove the obsolete option.
We refactor the `BasicBlockSections` pass by separating the BB address
map and BB sections handing to their own functions (named
`handleBBAddrMap` and `handleBBSections`). `handleBBSections` renumbers
basic blocks and places them in their assigned sections.
`handleBBAddrMap` is invoked after `handleBBSections` (if requested) and
only renumbers the blocks.
- New tests added:
- Two tests basic-block-address-map-with-basic-block-sections.ll and
basic-block-address-map-with-mfs.ll to exercise the combination of
`-basic-block-address-map` with `-basic-block-sections=list` and
'-split-machine-functions`.
- A driver sanity test for the `-fbasic-block-address-map` option
(basic-block-address-map.c).
- An LLD test for testing the `--lto-basic-block-address-map` option.
This reuses the LLVM IR from `lld/test/ELF/lto/basic-block-sections.ll`.
- Renamed and modified the two existing codegen tests for basic block
address map (`basic-block-sections-labels-functions-sections.ll` and
`basic-block-sections-labels.ll`)
- Removed `SHT_LLVM_BB_ADDR_MAP_V0` tests. Full deprecation of
`SHT_LLVM_BB_ADDR_MAP_V0` and `SHT_LLVM_BB_ADDR_MAP` version less than 2
will happen in a separate PR in a few months.
show more ...
|
Revision tags: llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
ea668144 |
| 04-Dec-2023 |
Nikita Popov <npopov@redhat.com> |
[CodeGen] Split off PseudoSourceValueManager into separate header (NFC) (#73327)
Most users of PseudoSourceValue.h only need PseudoSourceValue, not the
PseudoSourceValueManager. However, this heade
[CodeGen] Split off PseudoSourceValueManager into separate header (NFC) (#73327)
Most users of PseudoSourceValue.h only need PseudoSourceValue, not the
PseudoSourceValueManager. However, this header pulls in some very
expensive dependencies like ValueMap.h, which is only used for the
manager.
Split off the manager into a separate header and include it only where
used.
show more ...
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4 |
|
#
f70e39ec |
| 28-Oct-2023 |
Rahman Lavaee <rahmanl@google.com> |
[BasicBlockSections] Apply path cloning with -basic-block-sections. (#68860)
https://github.com/llvm/llvm-project/commit/28b912687900bc0a67cd61c374fce296b09963c4
introduced the path cloning format
[BasicBlockSections] Apply path cloning with -basic-block-sections. (#68860)
https://github.com/llvm/llvm-project/commit/28b912687900bc0a67cd61c374fce296b09963c4
introduced the path cloning format in the basic-block-sections profile.
This PR validates and applies path clonings.
A path cloning is valid if all of these conditions hold:
1. All bb ids in the path are mapped to existing blocks.
2. Each two consecutive bb ids in the path have a successor relationship
in the CFG.
3. The path does not include a block with indirect branches, except
possibly as the last block.
Applying a path cloning involves cloning all blocks in the path (except
the first one) and setting up their branches.
Once all clonings are applied, the cluster information is used to guide
block layout in the modified function.
show more ...
|
#
9a091de7 |
| 27-Oct-2023 |
Guozhi Wei <carrot@google.com> |
[X86, Peephole] Enable FoldImmediate for X86
Enable FoldImmediate for X86 by implementing X86InstrInfo::FoldImmediate.
Also enhanced peephole by deleting identical instructions after FoldImmediate.
[X86, Peephole] Enable FoldImmediate for X86
Enable FoldImmediate for X86 by implementing X86InstrInfo::FoldImmediate.
Also enhanced peephole by deleting identical instructions after FoldImmediate.
Differential Revision: https://reviews.llvm.org/D151848
show more ...
|
Revision tags: llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0 |
|
#
0a1aa6cd |
| 14-Sep-2023 |
Arthur Eubanks <aeubanks@google.com> |
[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)
This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future chang
[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)
This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future change to the params of
TargetMachine.
This matches other nearby enums.
For downstream users, this should be a fairly straightforward
replacement,
e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive
or s/CGFT_/CodeGenFileType::
show more ...
|