| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For code like:
float foo(float x) { return copysign(1.0, x); }
We used to generate:
andps <-0.000000e+00,0,0,0>, %xmm0
movss <1.000000e+00>, %xmm1
andps <nan>, %xmm1
orps %xmm0, %xmm1
Basically doing an abs(1.0f) in the two middle instructions.
We now generate:
andps <-0.000000e+00,0,0,0>, %xmm0
orps <1.000000e+00,0,0,0>, %xmm0
Builds on cleanups r223415, r223542.
rdar://19049548
Differential Revision: http://reviews.llvm.org/D6555
llvm-svn: 225357
|
| |
|
|
|
|
|
|
| |
The change in r225266 was reviewed under D6722. But the commit r225266 has a
typo, causing some MCHammer failures. This patch fixes it.
Change-Id: I573efcff25003af7478ac02548ebbe929fc7f5fd
llvm-svn: 225347
|
| |
|
|
|
|
| |
statement on the same variable. There was no additional code in the default so this should be no functional change.
llvm-svn: 225345
|
| |
|
|
|
|
| |
There is no handling for them.
llvm-svn: 225344
|
| |
|
|
| |
llvm-svn: 225343
|
| |
|
|
|
|
|
|
| |
Even thouh gcc produces simialr instructions as Owen pointed out the two patterns aren’t equivalent in the case
where the original subtraction could have caused an overflow.
Reverting the same.
llvm-svn: 225341
|
| |
|
|
| |
llvm-svn: 225331
|
| |
|
|
|
|
|
|
|
|
| |
Remove the README.txt entry regarding register allocation of CR logical ops,
and replace it with a FIXME in PPCInstrInfo.td. The text in the README.txt was
not really accurate, and thanks goes to Pat Haugen (and Bill Schmidt) from IBM
for clarifying what was intended and highlighting the relevant text in the ISA
specification.
llvm-svn: 225325
|
| |
|
|
|
|
|
|
| |
This is affecting the behavior of some ObjC++ / AArch64 test cases on Darwin.
Reverting to get the bots green while I track down the source of the changed
behavior.
llvm-svn: 225311
|
| |
|
|
| |
llvm-svn: 225310
|
| |
|
|
| |
llvm-svn: 225307
|
| |
|
|
| |
llvm-svn: 225306
|
| |
|
|
| |
llvm-svn: 225305
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
int->fp conversions on PPC must be done through memory loads and stores. On a
modern core, this process begins by storing the int value to memory, then
loading it using a (sometimes special) FP load instruction. Unfortunately, we
would do this even when the value to be converted was itself a load, and we can
just use that same memory location instead of copying it to another first.
There is a slight complication when handling int_to_fp(fp_to_int(x)) pairs,
because the fp_to_int operand has not been lowered when the int_to_fp is being
lowered. We handle this specially by invoking fp_to_int's lowering logic
(partially) and getting the necessary memory location (some trivial refactoring
was done to make this possible).
This is all somewhat ugly, and it would be nice if some later CodeGen stage
could just clean this stuff up, but because doing so would involve modifying
target-specific nodes (or instructions), it is not immediately clear how that
would work.
Also, remove a related entry from the README.txt for which we now generate
reasonable code.
llvm-svn: 225301
|
| |
|
|
| |
llvm-svn: 225291
|
| |
|
|
|
|
|
| |
This ensures that all memory operations are complete when all threads
reach the barrier.
llvm-svn: 225290
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In DS write instructions, the address operand comes before the value
operand(s) which is reversed from every other instruction type.
The SIInsertWait assumed that the first use for each instruction
was the value, so for DS write it was protecting the address
operand with s_waitcnt instructions when it should have been
protecting the value operand.
llvm-svn: 225289
|
| |
|
|
|
|
| |
dcfetch.
llvm-svn: 225283
|
| |
|
|
| |
llvm-svn: 225279
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is equivalent to the AMDGPUTargetMachine now, but it is the
starting point for separating R600 and GCN functionality into separate
targets.
It is recommened that users start using the gcn triple for GCN-based
GPUs, because using the r600 triple for these GPUs will be deprecated in
the future.
llvm-svn: 225277
|
| |
|
|
|
|
|
| |
The dump was dependent on a feature string, which meant that it couldn't
be disabled or enable on a per compile basis.
llvm-svn: 225275
|
| |
|
|
|
|
| |
Uses [GP] maintains existing behavior.
llvm-svn: 225270
|
| |
|
|
| |
llvm-svn: 225267
|
| |
|
|
|
|
|
|
|
|
|
| |
No functional changes. Support for ARM's modified immediate syntax was added
in r223113 and r223115 (review: D6408). That patch introduced the mod_imm*
tblegen definitions which renders the existing so_imm* definitions redundant.
This patch gets rid of them completely.
Reviewed as: D6722
llvm-svn: 225266
|
| |
|
|
|
|
| |
Requires new AsmParserOperand types that detect 16-bit and 32/64-bit mode so that we choose the right instruction based on default sizing without predicates. This is necessary since predicates mess up the disassembler table building.
llvm-svn: 225256
|
| |
|
|
|
|
|
|
| |
non-64-bit mode. Convert to the 1-byte form in non-64-bit mode as part of MCInst lowering.
Overall this seems simpler. It reduces duplication of patterns between both modes and it simplifies the memory folding/unfolding tables as they don't need to create fake instructions just to keep track of 64-bitness.
llvm-svn: 225252
|
| |
|
|
|
|
|
| |
Because of how Clang represents structs as arrays (at least on non-Darwin
platforms), and what SROA does, etc. this is no longer a problem.
llvm-svn: 225251
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
"ELF Handling for Thread-Local Storage" specifies that R_X86_64_GOTTPOFF
relocation target a movq or addq instruction.
Prohibit the truncation of such loads to movl or addl.
This fixes PR22083.
Differential Revision: http://reviews.llvm.org/D6839
llvm-svn: 225250
|
| |
|
|
|
|
| |
These are used for debugging output; NFC.
llvm-svn: 225249
|
| |
|
|
|
|
|
|
|
| |
The old target DAG combine that allowed for performing int_to_fp(fp_to_int(x))
without a load/store pair is updated here with support for unsigned integers,
and to support single-precision values without a third rounding step, on newer
cores with the appropriate instructions.
llvm-svn: 225248
|
| |
|
|
|
|
| |
We always select the 8-bit size and let the assembler backend relax to the larger size.
llvm-svn: 225243
|
| |
|
|
|
|
|
|
| |
long form.
The assembler backend will relax to the long form if necessary. This removes a swap from long form to short form in the MCInstLowering code. Selecting the long form used to be required by the old JIT.
llvm-svn: 225242
|
| |
|
|
| |
llvm-svn: 225233
|
| |
|
|
| |
llvm-svn: 225232
|
| |
|
|
| |
llvm-svn: 225231
|
| |
|
|
|
|
| |
I've filed http://llvm.org/PR22100 to track this issue.
llvm-svn: 225228
|
| |
|
|
| |
llvm-svn: 225227
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r225213. It's failing on multiple buildbots [1][2].
[1]: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/22032
[2]: http://lab.llvm.org:8080/green/view/Clang/job/clang-stage1-cmake-RA-incremental_check/2357/
llvm-svn: 225222
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We no longer generate horrible code for the stated function:
void f(signed char *a, _Bool b, _Bool c) {
signed char t = 0;
if (b) t = *a;
if (c) *a = t;
}
for which we now generate:
.L.f:
andi. 5, 5, 1
cmpldi 1, 4, 0
li 5, 0
beq 1, .LBB0_2
lbz 5, 0(3)
.LBB0_2: # %if.end
bclr 4, 1, 0
stb 5, 0(3)
blr
so we don't need the README.txt entry.
llvm-svn: 225217
|
| |
|
|
|
|
| |
Removed local isSequential predicate and use standard helper isSequentialOrUndefInRange instead.
llvm-svn: 225216
|
| |
|
|
|
|
|
| |
We now produce the desired code as noted in the README.txt file (no spurious
or). Remove the README entry and improve the regression test.
llvm-svn: 225214
|
| |
|
|
| |
llvm-svn: 225213
|
| |
|
|
|
|
|
| |
This entry has been rendered irrelevant now that we have proper CR bit
tracking.
llvm-svn: 225211
|
| |
|
|
|
|
| |
memop instructions. Removing old defs without bits and updating references.
llvm-svn: 225210
|
| |
|
|
|
|
|
| |
We now produce the desired code as noted in the README.txt file. Remove the
README entry and add a regression test.
llvm-svn: 225209
|
| |
|
|
|
|
|
| |
We now produce the desired code as noted in the README.txt file. Remove the
README entry and add a regression test.
llvm-svn: 225205
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this function from our README.txt file:
int foo(int a, int b) { return (a < b) << 4; }
We now explicitly track CR bits by default, so the comment in the README.txt
about not really having a SETCC is no longer accurate, but we did generate this
somewhat silly code:
cmpw 0, 3, 4
li 3, 0
li 12, 1
isel 3, 12, 3, 0
sldi 3, 3, 4
blr
which generates the zext as a select between 0 and 1, and then shifts the
result by a constant amount. Here we preprocess the DAG in order to fold the
results of operations on an extension of an i1 value into the SELECT_I[48]
pseudo instruction when the resulting constant can be materialized using one
instruction (just like the 0 and 1). This was not implemented as a DAGCombine
because the resulting code would have been anti-canonical and depends on
replacing chained user nodes, which does not fit well into the lowering
paradigm. Now we generate:
cmpw 0, 3, 4
li 3, 0
li 12, 16
isel 3, 12, 3, 0
blr
which is less silly.
llvm-svn: 225203
|
| |
|
|
| |
llvm-svn: 225202
|
| |
|
|
|
|
| |
accumulating shifts.
llvm-svn: 225201
|
| |
|
|
|
|
| |
encoding bits.
llvm-svn: 225199
|