| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
We need ppc instead of generic to override native features on ppc machines.
llvm-svn: 182049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes alias definition for addiu $rs,$imm
and instead uses the TwoOperandAliasConstraint field in
the ArithLogicI instruction class.
This way all instructions that inherit ArithLogicI class
have the same macro defined.
The usage examples are added to test files.
Patch by Vladimir Medic
llvm-svn: 182048
|
| |
|
|
| |
llvm-svn: 182047
|
| |
|
|
| |
llvm-svn: 182046
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some IR-level instructions (such as FP <-> i64 conversions) are not chained
w.r.t. the mtctr intrinsic and yet may become function calls that clobber the
counter register. At the selection-DAG level, these might be reordered with the
mtctr intrinsic causing miscompiles. To avoid this situation, if an existing
preheader has instructions that might use the counter register, create a new
preheader for the mtctr intrinsic. This extra block will be remerged with the
old preheader at the MI level, but will prevent unwanted reordering at the
selection-DAG level.
llvm-svn: 182045
|
| |
|
|
| |
llvm-svn: 182044
|
| |
|
|
| |
llvm-svn: 182043
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
emitting an
invalid instruction sequence.
Rather than emitting an int-to-FP move instruction and an int-to-FP conversion
instruction during instruction selection, we emit a pseudo instruction which gets
expanded post-RA. Without this change, register allocation can possibly insert a
floating point register move instruction between the two instructions, which is not
valid according to the ISA manual.
mtc1 $f4, $4 # int-to-fp move instruction.
mov.s $f2, $f4 # move contents of $f4 to $f2.
cvt.s.w $f0, $f2 # int-to-fp conversion.
llvm-svn: 182042
|
| |
|
|
| |
llvm-svn: 182041
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds bnez and beqz instructions which represent alias definitions for bne and beq instructions as follows:
bnez $rs,$imm => bne $rs,$zero,$imm
beqz $rs,$imm => beq $rs,$zero,$imm
The corresponding test cases are added.
Patch by Vladimir Medic
llvm-svn: 182040
|
| |
|
|
|
|
|
|
| |
synthesize a property getter method that overrides
a method definition named 'retain' and the like.
Fixes // rdar://13885083
llvm-svn: 182039
|
| |
|
|
|
|
|
|
|
|
|
|
| |
as the smaller type.
if ((x & 255) == 255)
before: movzbl %al, %eax
cmpl $255, %eax
after: cmpb $-1, %al
llvm-svn: 182038
|
| |
|
|
| |
llvm-svn: 182036
|
| |
|
|
| |
llvm-svn: 182035
|
| |
|
|
|
|
|
|
| |
This lane mask provides information about which register lanes
completely cover super-registers. See the block comment before
getCoveringLanes().
llvm-svn: 182034
|
| |
|
|
| |
llvm-svn: 182033
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the second part of the change to always return "true"
offset values from getPreIndexedAddressParts, tackling the
case of "memrix" type operands.
This is about instructions like LD/STD that only have a 14-bit
field to encode immediate offsets, which are implicitly extended
by two zero bits by the machine, so that in effect we can access
16-bit offsets as long as they are a multiple of 4.
The PowerPC back end currently handles such instructions by
carrying the 14-bit value (as it will get encoded into the
actual machine instructions) in the machine operand fields
for such instructions. This means that those values are
in fact not the true offset, but rather the offset divided
by 4 (and then truncated to an unsigned 14-bit value).
Like in the case fixed in r182012, this makes common code
operations on such offset values not work as expected.
Furthermore, there doesn't really appear to be any strong
reason why we should encode machine operands this way.
This patch therefore changes the encoding of "memrix" type
machine operands to simply contain the "true" offset value
as a signed immediate value, while enforcing the rules that
it must fit in a 16-bit signed value and must also be a
multiple of 4.
This change must be made simultaneously in all places that
access machine operands of this type. However, just about
all those changes make the code simpler; in many cases we
can now just share the same code for memri and memrix
operands.
llvm-svn: 182032
|
| |
|
|
| |
llvm-svn: 182031
|
| |
|
|
|
|
|
|
|
|
| |
OS X
- resolves llvm.org/pr14806
Patch by Matthew Sorrels!
llvm-svn: 182030
|
| |
|
|
| |
llvm-svn: 182029
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regions that aren't actually allocated in the
process. This cache is used by the expression
parser if the underlying process doesn't support
memory allocation, to avoid needless repeated
searches for unused address ranges.
Also fixed a silly bug in IRMemoryMap where it
would continue searching even after it found a
valid region.
<rdar://problem/13866629>
llvm-svn: 182028
|
| |
|
|
|
|
| |
It also refactors repetitive code in string.cpp do greatly reduce the repetitiveness, increasing maintainability.
llvm-svn: 182026
|
| |
|
|
|
|
| |
Fixed a 2 second delay when sending the 'k' (kill) packet that happened due to a race condition.
llvm-svn: 182025
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that we format:
void longFunctionName {
} // long comment here
And not:
void longFunctionName {}
// long comment here
As requested in post-commit-review.
llvm-svn: 182024
|
| |
|
|
|
|
|
| |
On PPC32, i64 FP conversions are implemented using runtime calls (which clobber
the counter register). These must be excluded.
llvm-svn: 182023
|
| |
|
|
| |
llvm-svn: 182022
|
| |
|
|
| |
llvm-svn: 182021
|
| |
|
|
|
|
|
|
|
| |
While testing some experimental code to add vector-scalar registers to
PowerPC, I noticed that a couple of independent instructions were
flipped by the scheduler. The new CHECK-DAG support is perfect for
avoiding this problem.
llvm-svn: 182020
|
| |
|
|
| |
llvm-svn: 182019
|
| |
|
|
| |
llvm-svn: 182018
|
| |
|
|
| |
llvm-svn: 182017
|
| |
|
|
|
|
| |
Without a PROLOG_LABEL present, the cfi instructions are never printed.
llvm-svn: 182016
|
| |
|
|
| |
llvm-svn: 182015
|
| |
|
|
|
|
|
|
|
|
| |
The recent improvement to the Use Nullptr Transform for macro arg
expansions wasn't testing that only allowed NULL macros used in macro
args can be transformed. This revision replaces a TODO to that effect.
Fixes PR15955.
llvm-svn: 182014
|
| |
|
|
|
|
|
| |
Several free functions related to macro arg testing are being moved into
CastSequenceVisitor to facilitate upcoming fix.
llvm-svn: 182013
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DAGCombiner::CombineToPreIndexedLoadStore calls a target routine to
decompose a memory address into a base/offset pair. It expects the
offset (if constant) to be the true displacement value in order to
perform optional additional optimizations; in particular, to convert
other uses of the original pointer into uses of the new base pointer
after pre-increment.
The PowerPC implementation of getPreIndexedAddressParts, however,
simply calls SelectAddressRegImm, which returns a TargetConstant.
This value is appropriate for encoding into the instruction, but
it is not always usable as true displacement value:
- Its type is always MVT::i32, even on 64-bit, where addresses
ought to be i64 ... this causes the optimization to simply
always fail on 64-bit due to this line in DAGCombiner:
// FIXME: In some cases, we can be smarter about this.
if (Op1.getValueType() != Offset.getValueType()) {
- Its value is truncated to an unsigned 16-bit value if negative.
This causes the above opimization to generate wrong code.
This patch fixes both problems by simply returning the true
displacement value (in its original type). This doesn't
affect any other user of the displacement.
llvm-svn: 182012
|
| |
|
|
| |
llvm-svn: 182011
|
| |
|
|
| |
llvm-svn: 182010
|
| |
|
|
|
|
|
| |
I am about to refactor the calls to addFrameMove and some of the ppc
ones were not being tested.
llvm-svn: 182009
|
| |
|
|
| |
llvm-svn: 182008
|
| |
|
|
| |
llvm-svn: 182007
|
| |
|
|
| |
llvm-svn: 182006
|
| |
|
|
|
|
| |
provided. On Linux this will use dl_iterate_phdr instead of /proc/self/maps, even if the symbolizer is not installed
llvm-svn: 182005
|
| |
|
|
| |
llvm-svn: 182004
|
| |
|
|
| |
llvm-svn: 182003
|
| |
|
|
|
|
| |
SanitizerAllocator64::PopulateFreeList().
llvm-svn: 182002
|
| |
|
|
| |
llvm-svn: 182001
|
| |
|
|
|
|
|
|
|
|
| |
This enables things like:
for (int &v : vec) v *= 2;
Enabled for Google style.
llvm-svn: 182000
|
| |
|
|
| |
llvm-svn: 181999
|
| |
|
|
|
|
| |
Added testcase corresponding to PR15991.
llvm-svn: 181998
|