| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 233079
|
|
|
|
| |
llvm-svn: 233078
|
|
|
|
| |
llvm-svn: 233077
|
|
|
|
|
|
|
| |
Other f64 opcodes not supported on SI can be lowered in a similar way.
v2: use complex VOP3 patterns
llvm-svn: 233076
|
|
|
|
|
|
|
|
|
| |
V_FRACT is buggy on SI.
R600-specific code is left intact.
v2: drop the multiclass, use complex VOP3 patterns
llvm-svn: 233075
|
|
|
|
|
|
|
|
| |
This reverts commit r233055.
It still causes buildbot failures (gcc running out of memory on several platforms, and a self-host failure on arm), although less than the previous time.
llvm-svn: 233068
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
The first time this was committed (r229831), it caused several buildbot failures.
At least some of the ARM ones were due to gcc/binutils issues, and should now be fixed.
Differential Revision: http://reviews.llvm.org/D8542
llvm-svn: 233055
|
|
|
|
|
|
|
|
|
|
| |
Simplify boolean expressions with `true` and `false` using `clang-tidy`
Patch by Richard Thomson.
Differential Revision: http://reviews.llvm.org/D8520
llvm-svn: 233020
|
|
|
|
| |
llvm-svn: 232998
|
|
|
|
|
|
|
| |
Don't use a separate table for compares anymore,
and use the same VOP2_REV class.
llvm-svn: 232992
|
|
|
|
|
|
| |
Also don't count the class instructions as isCompare anymore.
llvm-svn: 232991
|
|
|
|
|
|
| |
These are already set in the base class for the instruction.
llvm-svn: 232990
|
|
|
|
| |
llvm-svn: 232989
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables very common cases to switch to the
smaller encoding.
All of the standard LLVM canonicalizations of comparisons
are the opposite of what we want. Compares with constants
are moved to the RHS, but the first operand can be an inline
immediate, literal constant, or SGPR using the 32-bit VOPC
encoding.
There are additional bad canonicalizations that should
also be fixed, such as canonicalizing ge x, k to gt x, (k + 1)
if this makes k no longer an inline immediate value.
llvm-svn: 232988
|
|
|
|
|
|
| |
Use VOPCX_F64 to not need the let Defs = [EXEC]
llvm-svn: 232987
|
|
|
|
|
|
| |
It isn't used, and these will probably never be directly selected.
llvm-svn: 232986
|
|
|
|
|
|
| |
NFC.
llvm-svn: 232976
|
|
|
|
|
|
|
| |
This function assumed that SMRD instructions always have immediate
offsets, which is not always the case.
llvm-svn: 232957
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TargetMachine::getSubtargetImpl routines.
This keeps the target independent code free of bare subtarget
calls while the remainder of the backends are migrated, or not
if they don't wish to support per-function subtargets as would
be needed for function multiversioning or LTO of disparate
cpu subarchitecture types, e.g.
clang -msse4.2 -c foo.c -emit-llvm -o foo.bc
clang -c bar.c -emit-llvm -o bar.bc
llvm-link foo.bc bar.bc -o baz.bc
llc baz.bc
and get appropriate code for what the command lines requested.
llvm-svn: 232885
|
|
|
|
|
|
|
| |
bare target machine in preparation for the TargetMachine bare
getSubtarget/getSubtargetImpl calls going away.
llvm-svn: 232880
|
|
|
|
| |
llvm-svn: 232817
|
|
|
|
| |
llvm-svn: 232816
|
|
|
|
|
|
|
|
|
|
| |
multiple results.
This is needed for AVX512 masked scatter/gather support.
The R600 change is necessary to remove a hack that was working around the lack of multiple results.
llvm-svn: 232798
|
|
|
|
| |
llvm-svn: 232688
|
|
|
|
|
|
|
| |
This removes duplicated code from backends that don't need to do anything
fancy.
llvm-svn: 232658
|
|
|
|
| |
llvm-svn: 232481
|
|
|
|
|
|
|
| |
This avoids switching to .AMDGPU.config and back and hardcoding the
section it switches back to.
llvm-svn: 232479
|
|
|
|
| |
llvm-svn: 232429
|
|
|
|
| |
llvm-svn: 232428
|
|
|
|
|
|
|
|
|
| |
uppercase letter
This covers essentially all of llvm's headers and libs. One or two weird
cases I wasn't sure were worth/appropriate to fix.
llvm-svn: 232394
|
|
|
|
|
|
|
|
|
|
| |
There are no opcodes for this. This also adds a test case.
v2: make test more robust
Patch by: Grigori Goronzy
llvm-svn: 232386
|
|
|
|
|
|
|
|
| |
Fixes random crashes in for-loop piglit.
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com>
llvm-svn: 232181
|
|
|
|
|
|
| |
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com>
llvm-svn: 232180
|
|
|
|
|
|
| |
This is how the proprietary driver prints sopc instructions.
llvm-svn: 232106
|
|
|
|
|
|
|
|
| |
Instead print them as part of the $dst operand. The AsmMatcher
requires the 32-bit and 64-bit encodings have the same mnemonic in
order to parse them correctly.
llvm-svn: 232105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I don't know why every singled backend had to redeclare its own DataLayout.
There was a virtual getDataLayout() on the common base TargetMachine, the
default implementation returned nullptr. It was not clear from this that
we could assume at call site that a DataLayout will be available with
each Target.
Now getDataLayout() is no longer virtual and return a pointer to the
DataLayout member of the common base TargetMachine. I plan to turn it into
a reference in a future patch.
The only backend that didn't have a DataLayout previsouly was the CPPBackend.
It now initializes the default DataLayout. This commit is NFC for all the
other backends.
Test Plan: clang+llvm ninja check-all
Reviewers: echristo
Subscribers: jfb, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D8243
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231987
|
|
|
|
|
|
| |
classes.
llvm-svn: 231954
|
|
|
|
|
|
| |
we can inspect the subtarget and function when computing values.
llvm-svn: 231951
|
|
|
|
|
|
|
| |
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
|