2019-08-08 22:16:33 +00:00
|
|
|
set(LLVM_LINK_COMPONENTS
|
|
|
|
AllTargetsAsmParsers
|
|
|
|
AllTargetsCodeGens
|
|
|
|
AllTargetsDescs
|
|
|
|
AllTargetsInfos
|
2022-06-16 21:35:02 -04:00
|
|
|
Analysis
|
2021-11-24 09:23:52 +00:00
|
|
|
BitReader
|
2021-11-16 12:48:21 +00:00
|
|
|
BitWriter
|
2021-11-02 10:11:54 +01:00
|
|
|
CodeGen
|
2023-04-17 23:46:47 +09:00
|
|
|
CodeGenTypes
|
2019-08-08 23:00:28 +00:00
|
|
|
Core
|
2023-04-17 00:17:45 +09:00
|
|
|
IPO
|
2019-08-08 22:16:33 +00:00
|
|
|
IRReader
|
2021-11-02 10:11:54 +01:00
|
|
|
MC
|
|
|
|
MIRParser
|
2022-04-13 17:36:58 -07:00
|
|
|
Passes
|
2019-08-08 22:16:33 +00:00
|
|
|
Support
|
|
|
|
Target
|
[Support] Move TargetParsers to new component
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
2022-12-20 10:24:02 +00:00
|
|
|
TargetParser
|
2019-08-08 22:16:33 +00:00
|
|
|
TransformUtils
|
|
|
|
)
|
|
|
|
|
|
|
|
add_llvm_tool(llvm-reduce
|
2021-04-01 20:38:39 -07:00
|
|
|
DeltaManager.cpp
|
2021-11-02 10:11:54 +01:00
|
|
|
ReducerWorkItem.cpp
|
2019-08-08 22:16:33 +00:00
|
|
|
TestRunner.cpp
|
|
|
|
deltas/Delta.cpp
|
2022-06-21 17:30:52 -06:00
|
|
|
deltas/Utils.cpp
|
2020-10-28 13:06:42 +00:00
|
|
|
deltas/ReduceAliases.cpp
|
2020-02-05 14:15:11 -05:00
|
|
|
deltas/ReduceArguments.cpp
|
[llvm-reduce] Reducing attributes
Summary:
This handles all three places where attributes could currently be - `GlobalVariable`, `Function` and `CallBase`.
For last two, it correctly handles all three possible attribute locations (return value, arguments and function itself)
There was a previous attempt at it D73853,
which was committed in rGfc62b36a000681c01e993242b583c5ec4ab48a3c,
but then reverted all the way back in rGb12176d2aafa0ccb2585aa218fc3b454ba84f2a9
due to some (osx?) test failures.
Reviewers: nickdesaulniers, dblaikie, diegotf, george.burgess.iv, jdoerfert, Tyker, arsenm
Reviewed By: nickdesaulniers
Subscribers: wdng, MaskRay, arsenm, llvm-commits, mgorny
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83351
2020-07-09 23:06:59 +03:00
|
|
|
deltas/ReduceAttributes.cpp
|
2020-02-05 14:15:11 -05:00
|
|
|
deltas/ReduceBasicBlocks.cpp
|
2022-10-06 14:20:13 -07:00
|
|
|
deltas/ReduceDIMetadata.cpp
|
2024-08-20 12:34:41 +02:00
|
|
|
deltas/ReduceDistinctMetadata.cpp
|
2024-03-11 12:08:13 +00:00
|
|
|
deltas/ReduceDbgRecords.cpp
|
2020-07-25 21:43:36 +03:00
|
|
|
deltas/ReduceFunctionBodies.cpp
|
2020-07-07 01:16:37 +03:00
|
|
|
deltas/ReduceFunctions.cpp
|
2021-10-30 19:27:35 -07:00
|
|
|
deltas/ReduceGlobalObjects.cpp
|
2021-03-28 21:18:45 -07:00
|
|
|
deltas/ReduceGlobalValues.cpp
|
2021-01-02 19:56:27 +03:00
|
|
|
deltas/ReduceGlobalVarInitializers.cpp
|
2020-07-07 01:16:37 +03:00
|
|
|
deltas/ReduceGlobalVars.cpp
|
2020-02-05 14:15:11 -05:00
|
|
|
deltas/ReduceInstructions.cpp
|
2022-10-21 10:37:52 -07:00
|
|
|
deltas/ReduceInstructionFlags.cpp
|
2023-01-01 21:29:20 -05:00
|
|
|
deltas/ReduceInvokes.cpp
|
2020-07-07 01:16:37 +03:00
|
|
|
deltas/ReduceMetadata.cpp
|
2021-08-23 10:58:16 -07:00
|
|
|
deltas/ReduceModuleData.cpp
|
2022-10-21 14:03:51 -07:00
|
|
|
deltas/ReduceMemoryOperations.cpp
|
2020-07-07 01:16:37 +03:00
|
|
|
deltas/ReduceOperandBundles.cpp
|
2022-10-10 19:42:17 -07:00
|
|
|
deltas/ReduceOpcodes.cpp
|
2020-11-10 19:44:18 +00:00
|
|
|
deltas/ReduceSpecialGlobals.cpp
|
2021-09-17 12:18:03 -07:00
|
|
|
deltas/ReduceOperands.cpp
|
[llvm-reduce] Introduce operands-skip pass.
Add a new "operands-skip" pass whose goal is to remove instructions in the middle of dependency chains. For instance:
```
%baseptr = alloca i32
%arrayidx = getelementptr i32, i32* %baseptr, i32 %idxprom
store i32 42, i32* %arrayidx
```
might be reducible to
```
%baseptr = alloca i32
%arrayidx = getelementptr ... ; now dead, together with the computation of %idxprom
store i32 42, i32* %baseptr
```
Other passes would either replace `%baseptr` with undef (operands, instructions) or move it to become a function argument (operands-to-args), both of which might fail the interestingness check.
In principle the implementation allows operand replacement with any value or instruction in the function that passes the filter constraints (same type, dominance, "more reduced"), but is limited in this patch to values that are directly or indirectly used to compute the current operand value, motivated by the example above. Additionally, function arguments are added to the candidate set which helps reducing the number of relevant arguments mitigating a concern of too many arguments mentioned in https://reviews.llvm.org/D110274#3025013.
Possible future extensions:
* Instead of requiring the same type, bitcast/trunc/zext could be automatically inserted for some more flexibility.
* If undef is added to the candidate set, "operands-skip"is able to produce any reduction that "operands" can do. Additional candidates might be zero and one, where the "reductive power" classification can prefer one over the other. If undefined behaviour should not be introduced, undef can be removed from the candidate set.
Recommit after resolving conflict with D112651 and reusing
shouldReduceOperand from D113532.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D111818
2021-11-11 18:23:27 -06:00
|
|
|
deltas/ReduceOperandsSkip.cpp
|
2021-10-13 09:05:54 -05:00
|
|
|
deltas/ReduceOperandsToArgs.cpp
|
2021-11-02 10:11:54 +01:00
|
|
|
deltas/ReduceInstructionsMIR.cpp
|
2022-04-19 16:42:27 -04:00
|
|
|
deltas/ReduceInstructionFlagsMIR.cpp
|
2022-04-19 12:10:38 -04:00
|
|
|
deltas/ReduceIRReferences.cpp
|
2022-04-20 11:37:53 -04:00
|
|
|
deltas/ReduceVirtualRegisters.cpp
|
2022-06-22 13:13:17 -04:00
|
|
|
deltas/ReduceRegisterMasks.cpp
|
2022-06-27 14:28:33 -04:00
|
|
|
deltas/ReduceRegisterDefs.cpp
|
2022-04-22 11:44:37 -04:00
|
|
|
deltas/ReduceRegisterUses.cpp
|
2022-08-15 15:45:20 -06:00
|
|
|
deltas/ReduceUsingSimplifyCFG.cpp
|
2022-04-13 17:36:58 -07:00
|
|
|
deltas/RunIRPasses.cpp
|
2022-06-08 22:09:47 -04:00
|
|
|
deltas/SimplifyInstructions.cpp
|
2022-10-18 15:42:14 -07:00
|
|
|
deltas/StripDebugInfo.cpp
|
2020-07-07 01:16:37 +03:00
|
|
|
llvm-reduce.cpp
|
2019-08-08 22:16:33 +00:00
|
|
|
|
|
|
|
DEPENDS
|
|
|
|
intrinsics_gen
|
|
|
|
)
|