| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 215451
|
| |
|
|
| |
llvm-svn: 215441
|
| |
|
|
| |
llvm-svn: 215440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The combiner ignored DBG nodes when checking
the uses of a virtual register.
It combined a sequence like
%vreg1 = madd %vreg2, %vreg3,...
DBG_VALUE (%vreg1 ...)
%vreg4 = add %vreg1,...
to
%vreg4 = madd %vreg2, %vreg3
leaving behind a dangling DBG_VALUE with
a definition. This triggered an assertion
in the MachineTraceMetrics.cpp module.
llvm-svn: 215431
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Type::dump() doesn't print a newline, which makes for a poor
experience in a debugger. This looks like it was an ommission
considering Value::dump() two lines above, so I've changed Type to add
a newline as well.
Of the two in-tree callers, one added a newline anyway, and I've
updated the other one to use Type::print instead.
llvm-svn: 215421
|
| |
|
|
| |
llvm-svn: 215406
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
target hook.
This patch teaches the compiler that:
dX = VMOVDRR rY, rZ
is the same as:
dX = REG_SEQUENCE rY, ssub_0, rZ, ssub_1
<rdar://problem/12702965>
llvm-svn: 215404
|
| |
|
|
| |
llvm-svn: 215402
|
| |
|
|
|
|
| |
Have the comments match the actual parameter names. Found via clang-tidy.
llvm-svn: 215401
|
| |
|
|
|
|
|
| |
This saves us from having to copy a 64-bit 0 value into VGPRs for
BUFFER_* instruction which only have a 12-bit immediate offset.
llvm-svn: 215399
|
| |
|
|
| |
llvm-svn: 215398
|
| |
|
|
|
|
|
|
| |
This bit was left uninitialized, which was causing some random failures
of piglit tests.
NOTE: This is a candidate for the 3.5 branch.
llvm-svn: 215396
|
| |
|
|
|
|
|
|
| |
pre/post-index load and store.
Patch by Steven Wu <stevenwu@apple.com>
llvm-svn: 215390
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For many Thumb-1 register register instructions, setting the CPSR is not
permitted inside an IT block. We would not correctly flag those instructions.
The previous change to identify this scenario was insufficient as it did not
actually catch all the instances. The current list is formed by manual
inspection of the ARMv6M ARM.
The change to the Thumb2 IT block test is due to the fact that the new more
stringent checking of the MIs results in the If Conversion pass being prevented
from executing (since not all the instructions in the BB are predicable). This
results in code gen changes.
Thanks to Tim Northover for pointing out that the previous patch was
insufficient and hinting that the use of the v6M ARM would be much easier to use
than the v7 or v8!
llvm-svn: 215382
|
| |
|
|
|
|
|
| |
* libaries => libraries
* avaiable => available
llvm-svn: 215366
|
| |
|
|
|
|
|
|
| |
assembler directives
It seems to cause an lld test (elf/Mips/hilo16-3.test) to fail. Reverted while we investigate.
llvm-svn: 215361
|
| |
|
|
|
|
|
|
| |
Patch by Matheus Almeida and Toma Tabacu
Differential Revision: http://reviews.llvm.org/D4179
llvm-svn: 215359
|
| |
|
|
| |
llvm-svn: 215351
|
| |
|
|
|
|
|
|
|
|
|
|
| |
convention
By default, LLVM uses the "C" calling convention for all runtime
library functions. The half-precision FP conversion functions use the
soft-float calling convention, and are needed for some targets which
use the hard-float convention by default, so must have their calling
convention explicitly set.
llvm-svn: 215348
|
| |
|
|
|
|
| |
In a Clang bootstrap, their sizes were always 12, 16 and 16, respectively.
llvm-svn: 215336
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ARM ARM states that CPSR may not be updated by a MUL in thumb mode. Due to
an ordering of Thumb 2 Size Reduction and If Conversion, we would end up
generating a THUMB MULS inside an IT block.
The If Conversion pass uses the TTI isPredicable method to ensure that it can
transform a Basic Block. However, because we only check for IT handling on
Thumb2 functions, we may miss some cases. Even then, it only validates that the
CPSR is not *live* rather than it is not accessed. This corrects the handling
for that particular case since the same restriction does not hold on the vast
majority of the instructions.
This does prevent the IfConversion optimization from kicking in in certain
cases, but generating correct code is more valuable. Addresses PR20555.
llvm-svn: 215328
|
| |
|
|
|
|
|
| |
For ori, they are unsigned, for addi, signed. Create a new target
expression type to handle this and evaluate Fixups accordingly.
llvm-svn: 215315
|
| |
|
|
|
|
|
| |
At least on PowerPC, the interpretation of certain modifiers depends on
the context they appear in.
llvm-svn: 215310
|
| |
|
|
| |
llvm-svn: 215299
|
| |
|
|
|
|
| |
No functional changes intended.
llvm-svn: 215293
|
| |
|
|
| |
llvm-svn: 215286
|
| |
|
|
|
|
|
| |
since the operands are actually used on those cores. Provide aliases for
the only documented case in the newer Power ISA speec.
llvm-svn: 215282
|
| |
|
|
| |
llvm-svn: 215281
|
| |
|
|
|
|
| |
and update initialization.
llvm-svn: 215280
|
| |
|
|
| |
llvm-svn: 215279
|
| |
|
|
| |
llvm-svn: 215277
|
| |
|
|
|
|
| |
created.
llvm-svn: 215271
|
| |
|
|
|
|
|
| |
This will lower them using register copies rather than loads and stores
to the stack.
llvm-svn: 215270
|
| |
|
|
| |
llvm-svn: 215253
|
| |
|
|
| |
llvm-svn: 215240
|
| |
|
|
|
|
| |
empty functions will assert in the MC object writer.
llvm-svn: 215238
|
| |
|
|
|
|
|
|
| |
I accidentally also used INC/DEC for unsigned arithmetic which doesn't work,
because INC/DEC don't set the required flag which is used for the overflow
check.
llvm-svn: 215237
|
| |
|
|
|
|
|
|
| |
std::map invalidates the iterator to any element that gets deleted, which means
we can't increment it correctly afterwards. This was causing Darwin test
failures.
llvm-svn: 215233
|
| |
|
|
| |
llvm-svn: 215231
|
| |
|
|
|
|
|
|
|
|
| |
intrinsics.
This is a small peephole optimization to emit INC/DEC when possible.
Fixes <rdar://problem/17952308>.
llvm-svn: 215230
|
| |
|
|
| |
llvm-svn: 215226
|
| |
|
|
|
|
| |
soft-float is properly supported.
llvm-svn: 215221
|
| |
|
|
| |
llvm-svn: 215220
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
possible for -mno-abicalls to take effect.
Also added the testcase that should have been in r215194.
This behaviour has surprised me a few times now. The problem is that the
generated MipsSubtarget::ParseSubtargetFeatures() contains code like this:
if ((Bits & Mips::FeatureABICalls) != 0) IsABICalls = true;
so '-abicalls' means 'leave it at the default' and '+abicalls' means 'set it to
true'. In this case, (and the similar -modd-spreg case) I'd like the code to be
IsABICalls = (Bits & Mips::FeatureABICalls) != 0;
or possibly:
if ((Bits & Mips::FeatureABICalls) != 0)
IsABICalls = true;
else
IsABICalls = false;
and preferably arrange for 'Bits & Mips::FeatureABICalls' to be true by default
(on some triples).
llvm-svn: 215211
|
| |
|
|
|
|
|
|
| |
The bug can cause spec2006/483.xalancbmk failure.
Patched by David Xu.
llvm-svn: 215206
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For best-case performance on Cortex-A57, we should try to use a balanced mix of odd and even D-registers when performing a critical sequence of independent, non-quadword FP/ASIMD floating-point multiply or multiply-accumulate operations.
This pass attempts to detect situations where the register allocation may adversely affect this load balancing and to change the registers used so as to better utilize the CPU.
Ideally we'd just take each multiply or multiply-accumulate in turn and allocate it alternating even or odd registers. However, multiply-accumulates are most efficiently performed in the same functional unit as their accumulation operand. Therefore this pass tries to find maximal sequences ("Chains") of multiply-accumulates linked via their accumulation operand, and assign them all the same "color" (oddness/evenness).
This optimization affects S-register and D-register floating point multiplies and FMADD/FMAs, as well as vector (floating point only) muls and FMADD/FMA. Q register instructions (and 128-bit vector instructions) are not affected.
llvm-svn: 215199
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch implements the main rules for -mno-abicalls such as reserving $gp,
and emitting the correct .option directive.
Patch by Matheus Almeida and Toma Tabacu
Differential Revision: http://reviews.llvm.org/D4231
llvm-svn: 215194
|
| |
|
|
|
|
|
|
|
| |
This short-circuited our error reporting for incorrectly specified
target triples (you'd get AArch64 code instead).
Should fix PR20567.
llvm-svn: 215191
|
| |
|
|
|
|
|
|
| |
Patch provided by Andrey Kuharev.
Sorry, r170537 was obviously wrong.
llvm-svn: 215190
|
| |
|
|
| |
llvm-svn: 215180
|