| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 184969
|
|
|
|
|
|
| |
This allows for targeting the ARMv8 AArch32 variant.
llvm-svn: 184967
|
|
|
|
|
|
| |
consider them as a candidate for replacement of instructions to be visited.
llvm-svn: 184966
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately this addresses two issues (by the time I'd disentangled the logic
it wasn't worth putting it back to half-broken):
+ Coprocessor instructions should all be predicable in Thumb mode.
+ BKPT should never be predicable.
llvm-svn: 184965
|
|
|
|
|
|
|
| |
The barrier instructions are only "always-execute" in ARM mode, they can quite
happily sit inside an IT block in Thumb.
llvm-svn: 184964
|
|
|
|
|
|
| |
Make v4 the default ARM architecture attribute, to match CodeGen.
llvm-svn: 184962
|
|
|
|
| |
llvm-svn: 184960
|
|
|
|
| |
llvm-svn: 184955
|
|
|
|
|
|
| |
llvm itself is now PathV1 clean.
llvm-svn: 184947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The assembler currently strictly verifies that immediates for
s16imm operands are in range (-32768 ... 32767). This matches
the behaviour of the GNU assembler, with one exception: gas
allows, as a special case, operands in an extended range
(-65536 .. 65535) for the addis instruction only (and its
extended mnemonic lis).
The main reason for this seems to be to allow using unsigned
16-bit operands for lis, e.g. like lis %r1, 0xfedc.
Since this has been supported by gas for a long time, and
assembler source code seen "in the wild" actually exploits
this feature, this patch adds equivalent support to LLVM
for compatibility reasons.
llvm-svn: 184946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, all instructions taking s16imm operands support symbolic
operands. However, for u16imm operands, we only support actual
immediate integers. This causes the assembler to reject code like
ori %r5, %r5, symbol@l
This patch changes the u16imm operand definition to likewise
accept symbolic operands. In fact, s16imm and u16imm can
share the same encoding routine, now renamed to getImm16Encoding.
llvm-svn: 184944
|
|
|
|
| |
llvm-svn: 184943
|
|
|
|
|
|
| |
and loadRegFromStackSlot.
llvm-svn: 184935
|
|
|
|
| |
llvm-svn: 184933
|
|
|
|
| |
llvm-svn: 184932
|
|
|
|
|
|
| |
shift/xor/sub when it is possible. Fixed a bug in SDIV, where the const operand is not a splat constant vector.
llvm-svn: 184931
|
|
|
|
|
|
| |
more than the redzone size
llvm-svn: 184928
|
|
|
|
| |
llvm-svn: 184927
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Where a source tree is complete with lld, lldb and polly, it may not be possible to use cmake to configure build scripts if the host compiler it not capable of compiling these sub-projects. This change makes it possible to first build a bootstrap clang compiler when can then be used to build a complete llvm toolchain. An example bootstrap build sequence could be as follows:
$ mkdir bootstrap
$ cd bootstrap
$ cmake -G 'Unix Makefiles'
-DCMAKE_BUILD_TYPE:STRING=Release
-DCMAKE_PREFIX_PATH:STRING=$(pwd)
-DLLVM_TARGETS_TO_BUILD:STRING=host
-DLLVM_INCLUDE_TOOLS:STRING=bootstrap-only
../source
$ make clang # build clang only for host
$ cd ..
$ export CC=$(realpath bootstrap/bin)/clang
$ export CXX=$(realpath bootstrap/bin)/clang++
$ mkdir final
$ cd final
$ cmake -G 'Unix Makefiles' ../source
$ make all check-all
llvm-svn: 184924
|
|
|
|
| |
llvm-svn: 184923
|
|
|
|
|
|
| |
bots :-(
llvm-svn: 184920
|
|
|
|
| |
llvm-svn: 184919
|
|
|
|
| |
llvm-svn: 184917
|
|
|
|
| |
llvm-svn: 184916
|
|
|
|
|
|
| |
I will remove the V1 version as soon as I change clang in the next commit.
llvm-svn: 184914
|
|
|
|
| |
llvm-svn: 184910
|
|
|
|
|
|
|
| |
debug statements to add a missing newline. Also canonicalize to '\n' instead of
"\n"; the latter calls a function with a loop the former does not.
llvm-svn: 184897
|
|
|
|
| |
llvm-svn: 184892
|
|
|
|
|
|
| |
Prefer using RPO.lookup() instead of RPO[] which can mutate the map.
llvm-svn: 184891
|
|
|
|
| |
llvm-svn: 184888
|
|
|
|
|
|
|
|
|
| |
This is easier to read than the internal fixed-point representation.
If anybody knows the correct algorithm for converting fixed-point
numbers to base 10, feel free to fix it.
llvm-svn: 184881
|
|
|
|
| |
llvm-svn: 184880
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
|
|
|
|
|
|
| |
radar://14057959
llvm-svn: 184872
|
|
|
|
|
|
|
|
|
|
|
| |
When a 1-element vector alloca is promoted, a store instruction can often be
rewritten without converting the value to a scalar and using an insertelement
instruction to stuff it into the new alloca. This patch just adds a check
to skip that conversion when it is unnecessary. This turns out to be really
important for some ARM Neon operations where <1 x i64> is used to get around
the fact that i64 is not a legal type.
llvm-svn: 184870
|
|
|
|
| |
llvm-svn: 184866
|
|
|
|
| |
llvm-svn: 184864
|
|
|
|
|
|
|
| |
Add VK_... values and relocation types necessary to support
the @got family of modifiers. Used by the asm parser only.
llvm-svn: 184860
|
|
|
|
| |
llvm-svn: 184853
|
|
|
|
| |
llvm-svn: 184852
|
|
|
|
|
|
|
|
|
|
| |
By default, we expand these operations for both EG and SI. Move the
duplicated code into a common space for now. If the targets ever actually
implement these operations as instructions, we can override that in the relevant
target.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184848
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: Only adding test for evergreen, not SI yet.
When I attempted to expand vselect for SI, I got the following:
llc: /home/awatry/src/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:522:
llvm::SDValue llvm::DAGTypeLegalizer::PromoteIntRes_SETCC(llvm::SDNode*):
Assertion `SVT.isVector() == N->getOperand(0).getValueType().isVector() &&
"Vector compare must return a vector result!"' failed.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184847
|
|
|
|
|
|
|
| |
Add test cases for both vector sizes on SI and also add v2i32 test for EG.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184846
|
|
|
|
|
|
|
|
|
|
| |
No test/expansion for SI has been added yet. Attempts to expand this
operation for SI resulted in a stacktrace in (IIRC) LegalizeIntegerTypes
which was complaining about vector comparisons being required to return
a vector type.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184845
|
|
|
|
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Note: I followed the guidance of the v4i32 EG check... UREM produces really
complex code, so let's just check that the instruction was lowered
successfully.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184844
|
|
|
|
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Note: I followed the guidance of the v4i32 EG check... UDIV produces really
complex code, so let's just check that the instruction was lowered
successfully.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184843
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184842
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184841
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184840
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184839
|