History log of /llvm-project/llvm/lib/CodeGen/MIRParser/MIRParser.cpp (Results 1 – 25 of 194)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12345678