| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
update all ports accordingly. Required a couple of small rewrites
in handling subtarget features during creation in PPC.
llvm-svn: 231861
|
| |
|
|
|
|
|
| |
MCCodeEmitter creation routine based on TargetMachine since the only
64-bit R600 gpus are part of the GCN target.
llvm-svn: 231856
|
| |
|
|
| |
llvm-svn: 231798
|
| |
|
|
| |
llvm-svn: 231797
|
| |
|
|
|
|
|
| |
This fixes a machine verifier error in the salu-to-valu.ll, which
would have been exposed by a future commit.
llvm-svn: 231796
|
| |
|
|
|
|
|
| |
This was done by refactoring the v_cndmask_b32 tablegen definition
to use inherit from VOP2Inst.
llvm-svn: 231795
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that the DataLayout is a mandatory part of the module, let's start
cleaning the codebase. This patch is a first attempt at doing that.
This patch is not exactly NFC as for instance some places were passing
a nullptr instead of the DataLayout, possibly just because there was a
default value on the DataLayout argument to many functions in the API.
Even though it is not purely NFC, there is no change in the
validation.
I turned as many pointer to DataLayout to references, this helped
figuring out all the places where a nullptr could come up.
I had initially a local version of this patch broken into over 30
independant, commits but some later commit were cleaning the API and
touching part of the code modified in the previous commits, so it
seemed cleaner without the intermediate state.
Test Plan:
Reviewers: echristo
Subscribers: llvm-commits
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231740
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
clang-cl would warn that this value is not representable in 'int':
enum { FeatureX = 1ULL << 31 };
All MS enums are 'ints' unless otherwise specified, so we have to use an
explicit type. The AMDGPU target just hit 32 features, triggering this
warning.
Now that we have C++11 strong enum types, we can also eliminate the
'const uint64_t' codepath from tablegen and just use 'enum : uint64_t'.
llvm-svn: 231697
|
| |
|
|
|
|
| |
Also print it in the assembly string.
llvm-svn: 231684
|
| |
|
|
| |
llvm-svn: 231683
|
| |
|
|
| |
llvm-svn: 231663
|
| |
|
|
| |
llvm-svn: 231662
|
| |
|
|
|
|
| |
This is a candidate for stable.
llvm-svn: 231659
|
| |
|
|
| |
llvm-svn: 231658
|
| |
|
|
|
|
|
|
| |
In theory this allows the compiler to skip materializing the array on
the stack. In practice clang often fails to do that, but that's a
different story. NFC.
llvm-svn: 231571
|
| |
|
|
| |
llvm-svn: 231491
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
DataLayout keeps the string used for its creation.
As a side effect it is no longer needed in the Module.
This is "almost" NFC, the string is no longer
canonicalized, you can't rely on two "equals" DataLayout
having the same string returned by getStringRepresentation().
Get rid of DataLayoutPass: the DataLayout is in the Module
The DataLayout is "per-module", let's enforce this by not
duplicating it more than necessary.
One more step toward non-optionality of the DataLayout in the
module.
Make DataLayout Non-Optional in the Module
Module->getDataLayout() will never returns nullptr anymore.
Reviewers: echristo
Subscribers: resistor, llvm-commits, jholewinski
Differential Revision: http://reviews.llvm.org/D7992
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231270
|
| |
|
|
|
|
| |
Required by OpenGL (ARB_gpu_shader5).
llvm-svn: 231259
|
| |
|
|
|
|
| |
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <tom@stellard.net>
llvm-svn: 230987
|
| |
|
|
|
|
| |
Otherwise we have to emit thread-safe initialization for them. NFC.
llvm-svn: 230894
|
| |
|
|
| |
llvm-svn: 230846
|
| |
|
|
| |
llvm-svn: 230759
|
| |
|
|
|
|
|
|
| |
instructions
This matches the assembly syntax.
llvm-svn: 230758
|
| |
|
|
| |
llvm-svn: 230757
|
| |
|
|
|
|
| |
This matches the assembly syntax for the proprietary compiler.
llvm-svn: 230645
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
We legalize mubuf instructions post-instruction selection, so this
code is no longer needed.
llvm-svn: 230352
|
| |
|
|
| |
llvm-svn: 230149
|
| |
|
|
|
|
|
| |
This is a code size optimization when the constant
only has one use.
llvm-svn: 230148
|
| |
|
|
| |
llvm-svn: 230147
|
| |
|
|
| |
llvm-svn: 230146
|
| |
|
|
|
|
|
|
|
|
|
| |
Everyone except R600 was manually passing the length of a static array
at each callsite, calculated in a variety of interesting ways. Far
easier to let ArrayRef handle that.
There should be no functional change, but out of tree targets may have
to tweak their calls as with these examples.
llvm-svn: 230118
|
| |
|
|
|
|
|
|
|
|
| |
The expansion code does the same thing. Since
the operands were not defined with the correct
types, this has the side effect of fixing operand
folding since the expanded pseudo would never use
SGPRs or inline immediates.
llvm-svn: 230072
|
| |
|
|
|
|
|
|
|
|
|
| |
This enables a few useful combines that used to only
use fma.
Also since v_mad_f32 apparently does not support denormals,
disable the existing cases that are custom handled if they are
requested.
llvm-svn: 230071
|
| |
|
|
| |
llvm-svn: 229841
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
Differential Revision: http://reviews.llvm.org/D7065
llvm-svn: 229831
|
| |
|
|
|
|
| |
R600 port.
llvm-svn: 229804
|
| |
|
|
|
|
| |
asm printer and clean up a bunch of uses.
llvm-svn: 229803
|
| |
|
|
|
|
|
| |
up on the subtarget where it's set anyhow than looking it up
2-3 times in the same place.
llvm-svn: 229802
|
| |
|
|
| |
llvm-svn: 229789
|
| |
|
|
|
|
|
|
|
|
|
|
| |
VOP2 declares vsrc1, but VOP3 declares src1.
We can't use the same "ins" if the operands have different names in VOP2
and VOP3 encodings.
This fixes a hang in geometry shaders which spill M0 on VI.
(BTW it doesn't look like M0 needs spilling and the spilling seems
duplicated 3 times)
llvm-svn: 229752
|
| |
|
|
| |
llvm-svn: 229751
|
| |
|
|
|
|
| |
This should be handled by the OperandType checking.
llvm-svn: 229750
|
| |
|
|
|
|
|
| |
We only need to set this on pseudo instructions which won't
be used by the assembler.
llvm-svn: 229689
|
| |
|
|
| |
llvm-svn: 229688
|
| |
|
|
| |
llvm-svn: 229687
|
| |
|
|
| |
llvm-svn: 229686
|
| |
|
|
| |
llvm-svn: 229685
|
| |
|
|
| |
llvm-svn: 229684
|
| |
|
|
|
|
| |
The docs call this vdst instead of just dst.
llvm-svn: 229614
|