| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, not the
other way around).
llvm-svn: 318490
|
| |
|
|
|
|
| |
warnings.
llvm-svn: 318373
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Make it possible to feed runtime information back to tablegen to enable
profile-guided tablegen-eration, detection of untested tablegen definitions, etc.
Being a cross-compiler by nature, LLVM will potentially collect data for multiple
architectures (e.g. when running 'ninja check'). We therefore need a way for
TableGen to figure out what data applies to the backend it is generating at the
time. This patch achieves that by including the name of the 'def X : Target ...'
for the backend in the TargetRegistry.
Reviewers: qcolombet
Reviewed By: qcolombet
Subscribers: jholewinski, arsenm, jyknight, aditya_nandakumar, sdardis, nemanjai, ab, nhaehnle, t.p.northover, javed.absar, qcolombet, llvm-commits, fedor.sergeev
Differential Revision: https://reviews.llvm.org/D39742
llvm-svn: 318352
|
| |
|
|
|
|
|
| |
The Windows builder did not reconstruct the HexagonGenDAGISel.inc file
after the TableGen binary has changed.
llvm-svn: 317921
|
| |
|
|
|
|
| |
This reverts r317904: broke Windows build.
llvm-svn: 317916
|
| |
|
|
| |
llvm-svn: 317904
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, hasSideEffects was ? for TargetOpcode::PHI and would be inferred
as 1. D37065 sets the previously inferred properties explicitly. This patch sets
hasSideEffects=0 for PHI, as it is for G_PHI. MachineInstr::isSafeToMove has
been updated so it still returns false for PHI.
Additionally, HexagonBitSimplify relied on a PHI node having the
hasUnmodeledSideEffects property. This patch fixes that assumption.
Differential Revision: https://reviews.llvm.org/D37097
llvm-svn: 317721
|
| |
|
|
|
|
|
|
| |
This header includes CodeGen headers, and is not, itself, included by
any Target headers, so move it into CodeGen to match the layering of its
implementation.
llvm-svn: 317647
|
| |
|
|
|
|
|
|
|
| |
An "or" that sets the sign-bit can be replaced with a "xor", if
the sign-bit was known to be clear before. With some changes to
instruction combining, the simple sign-bit check was failing.
Replace it with a more flexible one to catch more cases.
llvm-svn: 317592
|
| |
|
|
|
|
|
|
|
|
|
| |
This header already includes a CodeGen header and is implemented in
lib/CodeGen, so move the header there to match.
This fixes a link error with modular codegeneration builds - where a
header and its implementation are circularly dependent and so need to be
in the same library, not split between two like this.
llvm-svn: 317379
|
| |
|
|
|
|
| |
of it in some cases where it is a more clear alternative to std::for_each.
llvm-svn: 317356
|
| |
|
|
|
|
|
| |
If the offset is an immediate, avoid putting it in a register
to get Rs+Rt<<#0.
llvm-svn: 317275
|
| |
|
|
| |
llvm-svn: 317091
|
| |
|
|
| |
llvm-svn: 317090
|
| |
|
|
| |
llvm-svn: 316904
|
| |
|
|
| |
llvm-svn: 316804
|
| |
|
|
|
|
|
| |
Making sure that an instruction has fewer operands than required, then
attempting to access one out of range is going to fail.
llvm-svn: 316785
|
| |
|
|
| |
llvm-svn: 316604
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In getOffsetRange, Max can be set to 0 to force the extender replacement
to be at or below the original value. This would cause the new offset to
be non-negative, which is preferred for memory instructions (to reduce
the likelihood of it getting constant-extended due to predication). The
problem happens when the range is shifted by an offset (present in the
instruction being examined) and the offset is negative. The entire range
for the allowable deviation will then be strictly negative. This creates
a problem, since 0 is assumed to be a valid deviation.
llvm-svn: 316601
|
| |
|
|
| |
llvm-svn: 316508
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In HexagonISelLowering, there is code to handle the case when
a function returns an i1 type. In this case, we need to generate
extra nodes to copy the result from R0 to a predicate register.
The code was returning the wrong value for the chain edge which
caused an assert "Wrong topological sorting" when converting the
instructions to MIs.
This patch fixes the problem by returning the chain for the final
copy.
Patch by Brendon Cahoon.
llvm-svn: 316367
|
| |
|
|
|
|
| |
One combination was missing: add(add(x,y),c).
llvm-svn: 316363
|
| |
|
|
| |
llvm-svn: 316271
|
| |
|
|
| |
llvm-svn: 316243
|
| |
|
|
| |
llvm-svn: 316236
|
| |
|
|
| |
llvm-svn: 316228
|
| |
|
|
|
|
|
|
|
|
|
| |
Normally, if the registers holding the induction variable's bounds
are redefined inside of the loop's body, the loop cannot be converted
to a hardware loop. However, if the redefining instruction is actually
loading an immediate value into the register, this conversion is both
possible and legal (since the immediate itself will be used in the
loop setup in the preheader).
llvm-svn: 316218
|
| |
|
|
| |
llvm-svn: 316170
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch lets the llvm tools handle the new HVX target features that
are added by frontend (clang). The target-features are of the form
"hvx-length64b" for 64 Byte HVX mode, "hvx-length128b" for 128 Byte mode HVX.
"hvx-double" is an alias to "hvx-length128b" and is soon will be deprecated.
The hvx version target feature is upgated form "+hvx" to "+hvxv{version_number}.
Eg: "+hvxv62"
For the correct HVX code generation, the user must use the following
target features.
For 64B mode: "+hvxv62" "+hvx-length64b"
For 128B mode: "+hvxv62" "+hvx-length128b"
Clang picks a default length if none is specified. If for some reason,
no hvx-length is specified to llvm, the compilation will bail out.
There is a corresponding clang patch.
Differential Revision: https://reviews.llvm.org/D38851
llvm-svn: 316101
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38850
llvm-svn: 316099
|
| |
|
|
|
|
|
|
| |
All loads of form V6_vL32b_{,cur,nt,tmp,nt_cur,nt_tmp}_{ai,pi,ppu} are
predicable on v62 (but not on v60). Mark them all as predicable in the
instruction definitions, and handle the v60 case in HII::isPredicable.
llvm-svn: 316098
|
| |
|
|
| |
llvm-svn: 315927
|
| |
|
|
|
|
| |
Recommit r315763 with a fix.
llvm-svn: 315925
|
| |
|
|
|
|
| |
This should silence "unused function" warnings.
llvm-svn: 315883
|
| |
|
|
|
|
|
|
| |
causing link errors for several people.
Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1
llvm-svn: 315854
|
| |
|
|
|
|
|
| |
GCC otherwise emits a "defined but not used" warning on the
member function.
llvm-svn: 315838
|
| |
|
|
|
|
| |
Broke some builds (using libstdc++).
llvm-svn: 315769
|
| |
|
|
| |
llvm-svn: 315763
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 315749
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each constant extender requires an extra instruction, which adds to the
code size and also reduces the number of available slots in an instruction
packet. In most cases, the value of a repeated constant extender could be
loaded into a register, and the instructions using the extender could be
replaced with their counterparts that use that register instead.
This patch adds a pass that tries to reduce the number of constant
extenders, including extenders which differ only in an immediate offset
known at compile time, e.g. @global and @global+12.
llvm-svn: 315735
|
| |
|
|
|
|
| |
Patch by Sumanth Gundapaneni.
llvm-svn: 315692
|
| |
|
|
|
|
|
|
|
|
| |
Reverting to investigate layering effects of MCJIT not linking
libCodeGen but using TargetMachine::getNameWithPrefix() breaking the
lldb bots.
This reverts commit r315633.
llvm-svn: 315637
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merge LLVMTargetMachine into TargetMachine.
- There is no in-tree target anymore that just implements TargetMachine
but not LLVMTargetMachine.
- It should still be possible to stub out all the various functions in
case a target does not want to use lib/CodeGen
- This simplifies the code and avoids methods ending up in the wrong
interface.
Differential Revision: https://reviews.llvm.org/D38489
llvm-svn: 315633
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.
Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.
Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so
it'll be picked up by public headers.
Differential Revision: https://reviews.llvm.org/D38406
llvm-svn: 315590
|
| |
|
|
|
|
|
|
| |
MCObjectStreamer owns its MCCodeEmitter -- this fixes the types to reflect that,
and allows us to remove the last instance of MCObjectStreamer's weird "holding
ownership via someone else's reference" trick.
llvm-svn: 315531
|
| |
|
|
| |
llvm-svn: 315510
|
| |
|
|
| |
llvm-svn: 315472
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The software pipeliner and the packetizer try to break dependence
between the post-increment instruction and the dependent memory
instructions by changing the base register and the offset value.
However, in some cases, the existing logic didn't work properly
and created incorrect offset value.
Patch by Jyotsna Verma.
llvm-svn: 315468
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pipeliner is generating a serial sequence that causes poor
register allocation when a post-increment instruction appears
prior to the use of the post-increment register. This occurs when
there is a circular set of dependences involved with a sequence
of instructions in the same cycle. In this case, there is no
serialization of the parallel semantics that will not cause an
additional register to be allocated.
This patch fixes the problem by changing the instructions so that
the post-increment instruction is used by the subsequent
instruction, which enables the register allocator to make a
better decision and not require another register.
Patch by Brendon Cahoon.
llvm-svn: 315466
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds debug tracing to the table-generated assembly instruction matcher,
enabled by the -debug-only=asm-matcher option.
The changes in the target AsmParsers are to add an MCInstrInfo reference under
a consistent name, so that we can use it from table-generated code. This was
already being used this way for targets that use deprecation warnings, but 5
targets did not have it, and Hexagon had it under a different name to the other
backends.
llvm-svn: 315445
|