Revision tags: llvmorg-21-init, llvmorg-19.1.7, 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, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
387bee91 |
| 13-Sep-2024 |
JOE1994 <joseph942010@gmail.com> |
[llvm][unittests] Strip unneeded uses of raw_string_ostream::str() (NFC)
Avoid excess layer of indirection.
|
Revision tags: 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, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1 |
|
#
184ca395 |
| 25-Jan-2024 |
Nico Weber <thakis@chromium.org> |
[llvm] Move CodeGenTypes library to its own directory (#79444)
Finally addresses https://reviews.llvm.org/D148769#4311232 :)
No behavior change.
|
Revision tags: llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, 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, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2 |
|
#
9cfeba5b |
| 10-Apr-2023 |
NAKAMURA Takumi <geek4civic@gmail.com> |
Restore CodeGen/LowLevelType from `Support`
This is rework of; - D30046 (LLT)
Since I have introduced `llvm-min-tblgen` as D146352, `llvm-tblgen` may depend on `CodeGen`.
`LowLevlType.h` origina
Restore CodeGen/LowLevelType from `Support`
This is rework of; - D30046 (LLT)
Since I have introduced `llvm-min-tblgen` as D146352, `llvm-tblgen` may depend on `CodeGen`.
`LowLevlType.h` originally belonged to `CodeGen`. Almost all userse are still under `CodeGen` or `Target`. I think `CodeGen` is the right place to put `LowLevelType.h`.
`MachineValueType.h` may be moved as well. (later, D149024)
I have made many modules depend on `CodeGen`. It is consistent but inefficient. It will be split out later, D148769
Besides, I had to isolate MVT and LLT in modmap, since `llvm::PredicateInfo` clashes between `TableGen/CodeGenSchedule.h` and `Transforms/Utils/PredicateInfo.h`. (I think better to introduce namespace llvm::TableGen)
Depends on D145937, D146352, and D148768.
Differential Revision: https://reviews.llvm.org/D148767
show more ...
|
Revision tags: llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3 |
|
#
b217a787 |
| 16-Aug-2022 |
Guozhi Wei <carrot@google.com> |
[unittests/CodeGen] Remove unique_ptr from the result of createTargetMachine
The object contained in unique_ptr will be automatically deleted at the end of the current scope. In createMachineFunctio
[unittests/CodeGen] Remove unique_ptr from the result of createTargetMachine
The object contained in unique_ptr will be automatically deleted at the end of the current scope. In createMachineFunction,
auto TM = createTargetMachine();
creates a TM contained in unique_ptr, a reference of the TM is stored in a MachineFunction object, but at the end of the function, the TM is deleted, so later access to the TM(and contained STI, TRI ...) through MachineFunction object is invalid.
So we should not use unique_ptr<BogusTargetMachine> in functions createMachineFunction and createTargetMachine.
Differential Revision: https://reviews.llvm.org/D131790
show more ...
|
Revision tags: llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
#
ed98c1b3 |
| 09-Mar-2022 |
serge-sans-paille <sguelton@redhat.com> |
Cleanup includes: DebugInfo & CodeGen
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121332
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
c2f819af |
| 23-May-2021 |
Philipp Krones <philipp.krones@embecosm.com> |
[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo
This makes it possible for targets to define their own MCObjectFileInfo. This MCObjectFileInfo is then used
[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo
This makes it possible for targets to define their own MCObjectFileInfo. This MCObjectFileInfo is then used to determine things like section alignment.
This is a follow up to D101462 and prepares for the RISCV backend defining the text section alignment depending on the enabled extensions.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101921
show more ...
|
#
632ebc4a |
| 05-May-2021 |
Philipp Krones <philipp.krones@embecosm.com> |
[MC] Untangle MCContext and MCObjectFileInfo
This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency a
[MC] Untangle MCContext and MCObjectFileInfo
This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency also exists during construction: You can't contruct a MOFI without a MCContext without constructing the MCContext with a dummy version of that MOFI first. This removes this dependency during construction. In a perfect world, MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the MCContext, like other MC information. This is future work.
This also shifts/adds more information to the MCContext making it more available to the different targets. Namely:
- TargetTriple - ObjectFileType - SubtargetInfo
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101462
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init |
|
#
de3d0ee0 |
| 09-Jan-2020 |
Daniel Sanders <daniel_l_sanders@apple.com> |
Revert "Revert "[MIR] Target specific MIR formating and parsing""
There was an unguarded dereference of MF in a function that permitted nullptr. Fixed
This reverts commit 71d64f72f934631aa2f12b9542
Revert "Revert "[MIR] Target specific MIR formating and parsing""
There was an unguarded dereference of MF in a function that permitted nullptr. Fixed
This reverts commit 71d64f72f934631aa2f12b9542c23f74f256f494.
show more ...
|
#
71d64f72 |
| 09-Jan-2020 |
Nico Weber <thakis@chromium.org> |
Revert "[MIR] Target specific MIR formating and parsing"
This reverts commit 3ef05d85be8c3666ebfa3ad986eb334da5195a47. It broke check-llvm on many bots, see comments on D69836.
|
#
3ef05d85 |
| 09-Jan-2020 |
Peng Guo <peng_guo@apple.com> |
[MIR] Target specific MIR formating and parsing
Summary: Added MIRFormatter for target specific MIR formating and parsing with immediate and custom pseudo source values. Target machine can subclass
[MIR] Target specific MIR formating and parsing
Summary: Added MIRFormatter for target specific MIR formating and parsing with immediate and custom pseudo source values. Target machine can subclass MIRFormatter and implement custom logic for printing and parsing immediate and custom pseudo source values for better readability.
* Target specific immediate mnemonic need to start with "." follows by identifier string. When MIR parser sees immediate it will call target specific parsing function.
* Custom pseudo source value need to start with custom follows by double-quoted string. MIR parser will pass the quoted string to target specific PSV parsing function.
* MIRFormatter have 2 helper functions to facilitate LLVM value printing and parsing for custom PSV if they refers LLVM values.
Patch by Peng Guo
Reviewers: dsanders, arsenm
Reviewed By: dsanders
Subscribers: wdng, jvesely, nhaehnle, hiraditya, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69836
show more ...
|
#
5ab6fa7b |
| 09-Jan-2020 |
Daniel Sanders <daniel_l_sanders@apple.com> |
Revert "[MIR] Target specific MIR formating and parsing"
Forgot to credit Peng in the commit message.
This reverts commit be841f89d0014b1e0246a4feae941b2f74abd908.
|
#
be841f89 |
| 09-Jan-2020 |
Peng Guo <peng_guo@apple.com> |
[MIR] Target specific MIR formating and parsing
Summary: Added MIRFormatter for target specific MIR formating and parsing with immediate and custom pseudo source values. Target machine can subclass
[MIR] Target specific MIR formating and parsing
Summary: Added MIRFormatter for target specific MIR formating and parsing with immediate and custom pseudo source values. Target machine can subclass MIRFormatter and implement custom logic for printing and parsing immediate and custom pseudo source values for better readability.
* Target specific immediate mnemonic need to start with "." follows by identifier string. When MIR parser sees immediate it will call target specific parsing function.
* Custom pseudo source value need to start with custom follows by double-quoted string. MIR parser will pass the quoted string to target specific PSV parsing function.
* MIRFormatter have 2 helper functions to facilitate LLVM value printing and parsing for custom PSV if they refers LLVM values.
Reviewers: dsanders, arsenm
Reviewed By: dsanders
Subscribers: wdng, jvesely, nhaehnle, hiraditya, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69836
show more ...
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2 |
|
#
d8e87227 |
| 01-Jun-2019 |
Eli Friedman <efriedma@quicinc.com> |
[CodeGen] Fix hashing for MO_ExternalSymbol MachineOperands.
We were hashing the string pointer, not the string, so two instructions could be identical (isIdenticalTo), but have different hash codes
[CodeGen] Fix hashing for MO_ExternalSymbol MachineOperands.
We were hashing the string pointer, not the string, so two instructions could be identical (isIdenticalTo), but have different hash codes.
This showed up as a very rare, non-deterministic assertion failure rehashing a DenseMap constructed by MachineOutliner. So there's no "real" testcase, just a unittest which checks that the hash function behaves correctly.
I'm a little scared fixing this is going to cause a regression in outlining or MachineCSE, but hopefully we won't run into any issues.
Differential Revision: https://reviews.llvm.org/D61975
llvm-svn: 362281
show more ...
|
Revision tags: llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2 |
|
#
43e94b15 |
| 31-Jan-2018 |
Puyan Lotfi <puyan@puyan.org> |
Followup on Proposal to move MIR physical register namespace to '$' sigil.
Discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html
In preparation for adding support for n
Followup on Proposal to move MIR physical register namespace to '$' sigil.
Discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html
In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs.
llvm-svn: 323922
show more ...
|
#
eb3f76fc |
| 18-Jan-2018 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
[CodeGen][NFC] Rename IsVerbose to IsStandalone in Machine*::print
Committed r322867 too soon.
Differential Revision: https://reviews.llvm.org/D42239
llvm-svn: 322868
|
#
378b5f3d |
| 18-Jan-2018 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
[CodeGen] Print RegClasses on MI in verbose mode
r322086 removed the trailing information describing reg classes for each register.
This patch adds printing reg classes next to every register when
[CodeGen] Print RegClasses on MI in verbose mode
r322086 removed the trailing information describing reg classes for each register.
This patch adds printing reg classes next to every register when individual operands/instructions/basic blocks are printed. In the case of dumping MIR or printing a full function, by default don't print it.
Differential Revision: https://reviews.llvm.org/D42239
llvm-svn: 322867
show more ...
|
Revision tags: llvmorg-6.0.0-rc1 |
|
#
ecd0b833 |
| 16-Jan-2018 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
[CodeGen][NFC] Correct case for printSubRegIdx
llvm-svn: 322541
|
#
fe6c9cbb |
| 10-Jan-2018 |
Puyan Lotfi <puyan@puyan.org> |
[MIR] Repurposing '$' sigil used by external symbols. Replacing with '&'.
Planning to add support for named vregs. This puts is in a conundrum since physregs are named as well. To rectify this we ne
[MIR] Repurposing '$' sigil used by external symbols. Replacing with '&'.
Planning to add support for named vregs. This puts is in a conundrum since physregs are named as well. To rectify this we need to use a sigil other than '%' for physregs in MIR. We've settled on using '$' for physregs but first we must repurpose it from external symbols using it, which is what this commit is all about. We think '&' will have familiar semantics for C/C++ users.
llvm-svn: 322146
show more ...
|
#
cb2683d4 |
| 19-Dec-2017 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
[CodeGen] Move printing MO_IntrinsicID operands to MachineOperand::print
Work towards the unification of MIR and debug output by refactoring the interfaces.
llvm-svn: 321112
|
#
bbd610ae |
| 19-Dec-2017 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
[CodeGen] Move printing MO_IntrinsicID operands to MachineOperand::print
Work towards the unification of MIR and debug output by refactoring the interfaces.
Also add support for printing with a nul
[CodeGen] Move printing MO_IntrinsicID operands to MachineOperand::print
Work towards the unification of MIR and debug output by refactoring the interfaces.
Also add support for printing with a null TargetIntrinsicInfo and no MachineFunction.
llvm-svn: 321111
show more ...
|
#
874ae6fa |
| 19-Dec-2017 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
[CodeGen] Move printing MO_CFIIndex operands to MachineOperand::print
Work towards the unification of MIR and debug output by refactoring the interfaces.
Before this patch we printed "<call frame i
[CodeGen] Move printing MO_CFIIndex operands to MachineOperand::print
Work towards the unification of MIR and debug output by refactoring the interfaces.
Before this patch we printed "<call frame instruction>" in the debug output.
llvm-svn: 321084
show more ...
|
#
3c99371c |
| 14-Dec-2017 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
[CodeGen] Print MCSymbol operands as <mcsymbol sym> in both MIR and debug output
Work towards the unification of MIR and debug output by printing `<mcsymbol sym>` instead of `<MCSym=sym>`.
Only deb
[CodeGen] Print MCSymbol operands as <mcsymbol sym> in both MIR and debug output
Work towards the unification of MIR and debug output by printing `<mcsymbol sym>` instead of `<MCSym=sym>`.
Only debug syntax is affected.
llvm-svn: 320685
show more ...
|
#
2db59382 |
| 14-Dec-2017 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
[CodeGen] Move printing MO_Metadata operands to MachineOperand::print
Work towards the unification of MIR and debug output by refactoring the interfaces.
llvm-svn: 320684
|