| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
By Asaf Badouh <asaf.badouh@intel.com>
llvm-svn: 230962
|
| |
|
|
|
|
|
| |
Fun fact: This file was never referenced since the initial checkin of
the NVPTX backend.
llvm-svn: 230957
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When the RHS of a conditional move node is zero, we can utilize the $zero
register by inverting the conditional move instruction and by swapping the
order of its True/False operands.
Reviewers: dsanders
Differential Revision: http://reviews.llvm.org/D7945
llvm-svn: 230956
|
| |
|
|
| |
llvm-svn: 230954
|
| |
|
|
|
|
| |
to reference more.
llvm-svn: 230931
|
| |
|
|
|
|
| |
doesn't fit in 5-bits. Fixes PR22743.
llvm-svn: 230924
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In AArch64PromoteConstant::appendAndTransferDominatedUses,
`InsertPts[NewPt]` invalidates IPI. Therefore, `InsertPts[NewPt] =
std::move(IPI->second)` is not legal.
This was caught by running `make check` with
http://reviews.llvm.org/D7931.
Reviewers: t.p.northover, grosbach, bkramer
Reviewed By: bkramer
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D7988
llvm-svn: 230923
|
| |
|
|
| |
llvm-svn: 230911
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With initializer lists there is a really neat idiomatic way to write
this, 'ArrayRef.equals({1, 2, 3, 4, 5})'. Remove the equal method which
always had a hard limit on the number of arguments. I considered
rewriting it with variadic templates but that's not really a good fit
for a function with homogeneous arguments.
'ArrayRef == {1, 2, 3, 4, 5}' would've been even more awesome, but C++11
doesn't allow init lists with binary operators.
llvm-svn: 230907
|
| |
|
|
|
|
| |
Otherwise we have to emit thread-safe initialization for them. NFC.
llvm-svn: 230894
|
| |
|
|
| |
llvm-svn: 230892
|
| |
|
|
|
|
| |
Added more tests for scalar instructions to destinguish between AVX and AVX-512 forms.
llvm-svn: 230891
|
| |
|
|
|
|
| |
represented by shuffle_vector instructions.
llvm-svn: 230860
|
| |
|
|
|
|
|
| |
complete the plumbing of passing TargetRegisterInfo through
computeRegisterProperties started by r230583
llvm-svn: 230858
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 230849
|
| |
|
|
| |
llvm-svn: 230846
|
| |
|
|
|
|
|
|
|
| |
All of the cases were just appending from random access iterators to a
vector. Using insert/append can grow the vector to the perfect size
directly and moves the growing out of the loop. No intended functionalty
change.
llvm-svn: 230845
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Straightforward patch to emit an alignment directive when emitting a
TOC entry. The test case was generated from the test in PR22711 that
demonstrated a misaligned .toc section. The object code is run
through llvm-readobj to verify that the correct alignment has been
applied to the .toc section.
Thanks to Ulrich Weigand for running down where the fix was needed.
llvm-svn: 230801
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Until now, we did this (among other things) based on whether or not the
target was Windows. This is clearly wrong, not just for Win64 ABI functions
on non-Windows, but for System V ABI functions on Windows, too. In this
change, we make this decision based on the ABI the calling convention
specifies instead.
Reviewers: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7953
llvm-svn: 230793
|
| |
|
|
|
|
|
|
|
|
| |
When using Altivec, we can use vector loads and stores for aligned memcpy and
friends. Starting with the P7 and VXS, we have reasonable unaligned vector
stores. Starting with the P8, we have fast unaligned loads too.
For QPX, we use vector loads are stores, but only for aligned memory accesses.
llvm-svn: 230788
|
| |
|
|
|
|
| |
Patch by Patrick Wildt.
llvm-svn: 230762
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7934
llvm-svn: 230760
|
| |
|
|
| |
llvm-svn: 230759
|
| |
|
|
|
|
|
|
| |
instructions
This matches the assembly syntax.
llvm-svn: 230758
|
| |
|
|
| |
llvm-svn: 230757
|
| |
|
|
|
|
|
|
|
|
|
|
| |
vectors. This lets us fix the rest of the v16 lowering problems when
pshufb is clearly better.
We might still be able to improve some of the lowerings by enabling the
other combine-based rewriting to fire for non-128-bit vectors, but this
at least should remove any regressions from using the fancy v16i16
lowering strategy.
llvm-svn: 230753
|
| |
|
|
|
|
|
| |
256-bit vectors as well as 128-bit vectors. Fixes some of the redundant
shuffles for v16i16.
llvm-svn: 230752
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
repeated 128-bit lane shuffles of wider vector types and use it to lower
256-bit v16i16 vector shuffles where applicable.
This should let us perfectly lowering the pattern of pshuflw and pshufhw
even for AVX2 256-bit patterns.
I've not added AVX-512 support, but it should be trivial for someone
working on that to wire up.
Note that currently this generates bad, long shuffle chains because we
don't combine 256-bit target shuffles. The subsequent patches will fix
that.
llvm-svn: 230751
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Also fixes an infringement of the 80-column limit rule.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7910
llvm-svn: 230748
|
| |
|
|
|
|
|
|
| |
going back through the entire vector shuffle lowering.
This is an important step to being able to re-use this logic.
llvm-svn: 230743
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We identify the cases where the operand to an ADDE node is a constant
zero. In such cases, we can avoid generating an extra ADDu instruction
disguised as an identity move alias (ie. addu $r, $r, 0 --> move $r, $r).
Reviewers: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7906
llvm-svn: 230742
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change causes us to actually save non-volatile registers in a Win64
ABI function that calls a System V ABI function, and vice-versa.
Reviewers: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7919
llvm-svn: 230714
|
| |
|
|
|
|
|
|
|
|
|
|
| |
uses of TM->getSubtargetImpl and propagate to all calls.
This could be a debugging regression in places where we had a
TargetMachine and/or MachineFunction but don't have it as part
of the MachineInstr. Fixing this would require passing a
MachineFunction/Function down through the print operator, but
none of the existing uses in tree seem to do this.
llvm-svn: 230710
|
| |
|
|
|
|
|
|
|
| |
a lookup, pass that in rather than use a naked call to getSubtargetImpl.
This involved passing down and around either a TargetMachine or
TargetRegisterInfo. Update all callers/definitions around the targets
and SelectionDAG.
llvm-svn: 230699
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
blend as legal.
We made the same mistake in two different places. Whenever we are custom
lowering a v32i8 blend we need to check whether we are custom lowering
it only for constant conditions that can be shuffled, or whether we
actually have AVX2 and full dynamic blending support on bytes. Both are
fixed, with comments added to make it clear what is going on and a new
test case.
llvm-svn: 230695
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamic blends.
This makes it much more clear what is going on. The case we're handling
is that of dynamic conditions, and we're bailing when the nature of the
vector types and subtarget preclude lowering the dynamic condition
vselect as an actual blend.
No functionality changed here, but this will make a subsequent bug-fix
to this code much more clear.
llvm-svn: 230690
|
| |
|
|
|
|
|
| |
change functionality, but makes it more clear that the dynamic case and
the shuffle case don't overlap in any interesting way.
llvm-svn: 230689
|
| |
|
|
|
|
| |
AVX2.
llvm-svn: 230688
|
| |
|
|
|
|
|
|
| |
The shadow stack space expectations won't match.
Fixes PR22709.
llvm-svn: 230667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a problem when passing structures as variable arguments.
The structures smaller than 64 bit were not left justified on MIPS64
big endian. This is now fixed by shifting the value to make it left-
justified when appropriate.
This fixes the bug http://llvm.org/bugs/show_bug.cgi?id=21608
Patch by Aleksandar Beserminji.
Differential Revision: http://reviews.llvm.org/D7881
llvm-svn: 230657
|
| |
|
|
|
|
|
|
|
|
|
| |
In case of "krait" CPU, asm printer doesn't emit any ".cpu" so the
features bits are not computed. This patch lets the asm printer
emit ".cpu cortex-a9" directive for krait and the hwdiv feature is
enabled through ".arch_extension". In short, krait is treated
as "cortex-a9" with hwdiv. We can not emit ".krait" as CPU since
it is not supported bu GNU GAS yet
llvm-svn: 230651
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch is in response to r223147 where the avaiable features are
computed based on ".cpu" directive. This will work clean for the standard
variants like cortex-a9. For custom variants which rely on standard cpu names
for assembly, the additional features of a CPU should be propagated. This can be
done via ".arch_extension" as long as the assembler supports it. The
implementation for krait along with unit test will be submitted in next patch.
llvm-svn: 230650
|
| |
|
|
|
|
| |
This matches the assembly syntax for the proprietary compiler.
llvm-svn: 230645
|
| |
|
|
|
|
|
| |
The latency for the WriteMULm class was set to 4, which is actually lower than the latency for WriteMULr (5).
A better estimate would be 4 added to WriteMULr, that is, 9.
llvm-svn: 230634
|
| |
|
|
|
|
|
|
|
|
| |
formulaic into the top v8i16 lowering routine.
This makes the generalized lowering a completely general and single path
lowering which will allow generalizing it in turn for multiple 128-bit
lanes.
llvm-svn: 230623
|
| |
|
|
|
|
| |
MVT.
llvm-svn: 230622
|
| |
|
|
|
|
| |
This ordering matches that of DAG.getNode.
llvm-svn: 230617
|
| |
|
|
|
|
|
| |
It still prints "Assembling path/to/X86CompilationCallback_Win64.asm",
but linking does the same thing.
llvm-svn: 230596
|
| |
|
|
|
|
|
|
|
|
| |
Explanation: This function is in TargetLowering because it uses
RegClassForVT which would need to be moved to TargetRegisterInfo
and would necessitate moving isTypeLegal over as well - a massive
change that would just require TargetLowering having a TargetRegisterInfo
class member that it would use.
llvm-svn: 230585
|
| |
|
|
|
|
|
|
|
| |
This required plumbing a TargetRegisterInfo through computeRegisterProperties
and into findRepresentativeClass which uses it for register class
iteration. This required passing a subtarget into a few target specific
initializations of TargetLowering.
llvm-svn: 230583
|