| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 276675
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some targets, notably AArch64 for ILP32, have different relocation encodings
based upon the ABI. This is an enabling change, so a future patch can use the
ABIName from MCTargetOptions to chose which relocations to use. Tested using
check-llvm.
The corresponding change to clang is in: http://reviews.llvm.org/D16538
Patch by: Joel Jones
Differential Revision: https://reviews.llvm.org/D16213
llvm-svn: 276654
|
| |
|
|
|
|
|
|
| |
It failed with assertion before this patch.
Differential Revision: https://reviews.llvm.org/D22735
llvm-svn: 276648
|
| |
|
|
| |
llvm-svn: 276638
|
| |
|
|
|
|
|
|
| |
Added thumb targets and dataflow checks to the longMAC test.
Differential Revision: https://reviews.llvm.org/D22684
llvm-svn: 276629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid MipsAnalyzeImmediate usage if the constant fits in an 32-bit
integer. This allows us to generate the same instructions for the
materialization of the same constants regardless the width of their
type.
Patch by: Vasileios Kalintiris
Contributions by: Simon Dardis
Reviewers: Daniel Sanders
Differential Review: https://reviews.llvm.org/D21689
llvm-svn: 276628
|
| |
|
|
|
|
|
|
|
| |
Follow up to r276624. Changes bits 22-20 to be parameters to
instruction class.
Differential Revision: https://reviews.llvm.org/D22562
llvm-svn: 276626
|
| |
|
|
|
|
|
|
| |
Use ISelDAGToDAG to recognise the SMMLS instruction pattern.
Differential Revision: https://reviews.llvm.org/D22562
llvm-svn: 276624
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 276615
|
| |
|
|
|
|
| |
the first argument of an FMADD/FMSUB/FNMADD/FNMSUB/FMADDSUB/FMSUBADD node. Also add patterns to support all combinations of the broadcast input and the preserved input for masked versions.
llvm-svn: 276614
|
| |
|
|
|
|
| |
to really be 213, 231, and 132.
llvm-svn: 276613
|
| |
|
|
|
|
| |
As with all AMD CPUs, excavator has poor SHLD/SHRD performance. Also added bdver3 to the test as it was missing.
llvm-svn: 276569
|
| |
|
|
|
|
|
|
| |
encoded versions.
This places the 132/213/231 form number in front of the SS/SD/PS/PD. Move the Y for 256-bit versions to be after the PS/PD. Change the AVX512 scalar forms to include a Z in the their name. This new format should be consistent with the general naming of instructions.
llvm-svn: 276559
|
| |
|
|
|
|
| |
the operand types exactly match the normal VPSRAVW/D/Q instructions.
llvm-svn: 276555
|
| |
|
|
| |
llvm-svn: 276528
|
| |
|
|
|
|
|
| |
should fix the build with GCC 4.9 at least. Not sure if this is the
right name or fix, but I've followed up on the original commit.
llvm-svn: 276522
|
| |
|
|
| |
llvm-svn: 276521
|
| |
|
|
|
|
| |
just to get the IsIntrisic flag, instead get it during the first call and pass it along. NFC
llvm-svn: 276520
|
| |
|
|
| |
llvm-svn: 276519
|
| |
|
|
|
|
| |
This has been dead since r269479
llvm-svn: 276518
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r276298.
Data stored in .rodata can have a negative offset from .text, but we
don't support negative values in relocations yet.
This caused a regression in one of the amp conformance tests:
5_Data_Cont/5_2_a_v/5_2_3_m/Assignment/Test.02.01
llvm-svn: 276498
|
| |
|
|
| |
llvm-svn: 276465
|
| |
|
|
|
|
|
|
|
| |
This adds the actual MachineLegalizeHelper to do the work and a trivial pass
wrapper that legalizes all instructions in a MachineFunction. Currently the
only transformation supported is splitting up a vector G_ADD into one acting on
smaller vectors.
llvm-svn: 276461
|
| |
|
|
|
|
| |
Hexagon backend uses LoopDataPrefetch pass that is defined in Scalar.
llvm-svn: 276441
|
| |
|
|
|
|
|
|
|
| |
The size can exceed s_movk_i32's limit, and we don't
want to use it this early since it inhibits optimizations.
This should probably be merged to the release branch.
llvm-svn: 276438
|
| |
|
|
| |
llvm-svn: 276437
|
| |
|
|
|
|
|
| |
Remove dead code from r600 intrinsic removal.
Remove unset members, rename StackSize to be less ambiguous.
llvm-svn: 276436
|
| |
|
|
|
|
|
| |
R600's i1 fp_to_uint selected but was incorrect according to
what instcombine constant folds to.
llvm-svn: 276435
|
| |
|
|
| |
llvm-svn: 276434
|
| |
|
|
|
|
|
|
|
| |
- FuncNode::findBlock traverses the function every time. Avoid using it,
and keep a cache of block addresses in DataFlowGraph instead.
- The operator[] in the map of definition stacks was very slow. Replace
the map with unordered_map.
llvm-svn: 276429
|
| |
|
|
| |
llvm-svn: 276422
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(reapplied)
As reported on PR26235, we don't currently make use of the VBROADCASTF128/VBROADCASTI128 instructions (or the AVX512 equivalents) to load+splat a 128-bit vector to both lanes of a 256-bit vector.
This patch enables lowering from subvector insertion/concatenation patterns and auto-upgrades the llvm.x86.avx.vbroadcastf128.pd.256 / llvm.x86.avx.vbroadcastf128.ps.256 intrinsics to match.
We could possibly investigate using VBROADCASTF128/VBROADCASTI128 to load repeated constants as well (similar to how we already do for scalar broadcasts).
Reapplied with fix for PR28657 - removed intrinsic definitions (clang companion patch to be be submitted shortly).
Differential Revision: https://reviews.llvm.org/D22460
llvm-svn: 276416
|
| |
|
|
|
|
|
|
| |
It caused PR28657.
This reverts commit r276281.
llvm-svn: 276405
|
| |
|
|
|
|
|
|
|
| |
functions so that the size computation is available not only in ConstantIslands
but in other passes as well.
Differential Revision: https://reviews.llvm.org/D22640
llvm-svn: 276399
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D19906
llvm-svn: 276397
|
| |
|
|
| |
llvm-svn: 276394
|
| |
|
|
|
|
| |
some EVEX instructions.
llvm-svn: 276393
|
| |
|
|
| |
llvm-svn: 276392
|
| |
|
|
| |
llvm-svn: 276391
|
| |
|
|
|
|
| |
encoded instructions too.
llvm-svn: 276390
|
| |
|
|
|
|
|
|
| |
Use the machinery in MathExtras instead of rolling it by hand.
This fixes PR28624.
llvm-svn: 276366
|
| |
|
|
| |
llvm-svn: 276362
|
| |
|
|
|
|
|
| |
This variant is (as documented in the TD) for disassembler use only, and should
not be used in patterns - it is longer, and is broken on 64-bit.
llvm-svn: 276347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when constraint "w" is used on a 32-bit operand.
This enables compiling the following code, which used to error out in
the backend:
void foo1(int a) {
asm volatile ("sqxtn h0, %s0\n" : : "w"(a):);
}
Fixes PR28633.
llvm-svn: 276344
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22538
llvm-svn: 276298
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D21646
llvm-svn: 276294
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
limits.
Summary:
This change also changes findMatchingInsn and
findMatchingUpdateInsnForward to take DBG_VALUE opcodes into account
when tracking register defs and uses, which could potentially inhibit
these optimizations in the presence of debug information.
Reviewers: mcrosier
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D22582
llvm-svn: 276293
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under normal circumstances we prefer the higher performance MOVD to extract the 0'th element of a v8i16 vector instead of PEXTRW.
But as detailed on PR27265, this prevents the SSE41 implementation of PEXTRW from folding the store of the 0'th element. Additionally it prevents us from making use of the fact that the (SSE2) reg-reg version of PEXTRW implicitly zero-extends the i16 element to the i32/i64 destination register.
This patch only preferentially lowers to MOVD if we will not be zero-extending the extracted i16, nor prevent a store from being folded (on SSSE41).
Fix for PR27265.
Differential Revision: https://reviews.llvm.org/D22509
llvm-svn: 276289
|
| |
|
|
|
|
| |
As requested on D22509, I've pulled out the v8i16 extraction lowering as the SSE41 and pre-SSE41 implementations are effectively the same.
llvm-svn: 276285
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As reported on PR26235, we don't currently make use of the VBROADCASTF128/VBROADCASTI128 instructions (or the AVX512 equivalents) to load+splat a 128-bit vector to both lanes of a 256-bit vector.
This patch enables lowering from subvector insertion/concatenation patterns and auto-upgrades the llvm.x86.avx.vbroadcastf128.pd.256 / llvm.x86.avx.vbroadcastf128.ps.256 intrinsics to match.
We could possibly investigate using VBROADCASTF128/VBROADCASTI128 to load repeated constants as well (similar to how we already do for scalar broadcasts).
Differential Revision: https://reviews.llvm.org/D22460
llvm-svn: 276281
|