Warning was:
  Argument not separated from preceding token by whitespace.

llvm-svn: 188701

- split WidenVecRes_Binary into WidenVecRes_Binary and WidenVecRes_BinaryCanTrap
  - WidenVecRes_BinaryCanTrap preserves the original behaviour for operations
    that can trap
  - WidenVecRes_Binary simply widens the operation and improves codegen for
    3-element vectors by allowing widening and promotion on x86 (matches the
    behaviour of unary and ternary operation widening)
- use WidenVecRes_Binary for operations on integers.

Reviewed by: nrotem

llvm-svn: 188699

llvm-svn: 188697

llvm-svn: 188690

futher commits.

llvm-svn: 188689

Differential Revision: http://llvm-reviews.chandlerc.com/D1437

llvm-svn: 188688

The Thumb2 add immediate is in fact defined for SP. The manual is misleading as it points to a different section for add immediate with SP, however the encoding is the same as for add immediate with register only with the SP operand hard coded. As such add immediate with SP and add immediate with register can safely be treated as the same instruction.

All the patch does is adjust a register constraint on an instruction alias.

llvm-svn: 188676

ADD, SUB, MUL integer and FP types. OR, AND, XOR.
Added embeded broadcast form for these instructions.

llvm-svn: 188673

For now this matches the equivalent of (neg (abs ...)), which did hit a few
times in projects/test-suite.  We should probably also match cases where
absolute-like selects are used with reversed arguments.

llvm-svn: 188671

llvm-svn: 188670

This first cut is pretty conservative.  The final argument register (R6)
is call-saved, so we would need to make sure that the R6 argument to a
sibling call is the same as the R6 argument to the calling function,
which seems worth keeping as a separate patch.

Saying that integer truncations are free means that we no longer
use the extending instructions LGF and LLGF for spills in int-conv-09.ll
and int-conv-10.ll.  Instead we treat the registers as 64 bits wide and
truncate them to 32-bits where necessary.  I think it's unlikely we'd
use LGF and LLGF for spills in other situations for the same reason,
so I'm removing the tests rather than replacing them.  The associated
code is generic and applies to many more instructions than just
LGF and LLGF, so there is no corresponding code removal.

llvm-svn: 188669

* pow(x, 0.5) -> fabs(sqrt(x)) 
* pow(2.0, x) -> exp2(x)

llvm-svn: 188656

We had previously been asserting when faced with a FCOPYSIGN f64, ppcf128 node
because there was no way to expand the FCOPYSIGN node. Because ppcf128 is the
sum of two doubles, and the first double must have the larger magnitude, we
can take the sign from the first double. As a result, in addition to fixing the
crash, this is also an optimization.

llvm-svn: 188655

llvm-svn: 188654

Modern PPC cores support a floating-point copysign instruction, and we can use
this to lower the FCOPYSIGN node (which is created from calls to the libm
copysign function). A couple of extra patterns are necessary because the
operand types of FCOPYSIGN need not agree.

llvm-svn: 188653

This reduces the noise in diffs making it more likely that, at least for
LLVM revision-over-revision, diffs will actually yield usable results.

This is consistent with objdump's DWARF dumping behavior.

llvm-svn: 188650

We check this in many/all other cases, just missed this one it seems.
Perhaps it'd be worth unifying this so we never emit zero-length
DW_AT_names.

llvm-svn: 188649

It turned out that I didn't need this for DFSan.

llvm-svn: 188646

When patching inlineasm nodes to use GPRPair for 64-bit values, we
were dropping the information that two operands were tied, which
effectively broke the live-interval of vregs affected.

llvm-svn: 188643

llvm-svn: 188637

llvm-svn: 188629

llvm-svn: 188627

llvm-svn: 188626

llvm-svn: 188620

llvm-svn: 188619

project's autoconf. This is the last of the missing optional checks used
by libSupport that seemed to be missing from the sample project, but
I could easily have missed some as this was done by inspection when
Craig asked me to add the terminfo support.

llvm-svn: 188618

autoconf setup.

llvm-svn: 188617

detecting terminfo. Requested by Craig Topper, and probably should be
done much more systematically.

llvm-svn: 188616

allocated by setupterm. Without this, some folks are seeing leaked
memory whenever this routine is called more than once. Thanks to Craig
Topper for the report.

llvm-svn: 188615

This fixes SCEVExpander so that it does not create multiple distinct induction
variables for duplicate PHI entries. Specifically, given some code like this:

do.body6:                                         ; preds = %do.body6, %do.body6, %if.then5
  %end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...

Note that it is legal to have multiple entries for a basic block so long as the
associated value is the same. So the above input is okay, but expanding an
AddRec in this loop could produce code like this:

do.body6:                                         ; preds = %do.body6, %do.body6, %if.then5
  %indvar = phi i64 [ %indvar.next, %do.body6 ], [ %indvar.next1, %do.body6 ], [ 0, %if.then5 ]
  %end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...
  %indvar.next = add i64 %indvar, 1
  %indvar.next1 = add i64 %indvar, 1

And this is not legal because there are two PHI entries for %do.body6 each with
a distinct value.

Unfortunately, I don't have an in-tree test case.

llvm-svn: 188614

builtin. The GCC builtin expects the arguments to be passed by val,
whereas the LLVM intrinsic expects a pointer instead.

This is related to PR 16581 and rdar:14747994.

llvm-svn: 188608

llvm-svn: 188606

next value. This avoids crashes due to invalidation.

Patch by Joey Gouly.

llvm-svn: 188605

Spotted by Nick Lewycky!

llvm-svn: 188599

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 188598

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 188597

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 188596

Ongoing 'make the verifier happy' improvements to ARM fast-isel.

rdar://12594152

llvm-svn: 188595

Properly constrain the operand register class for instructions used
in [sz]ext expansion. Update more tests to use the verifier now that
we're getting the register classes correct.

rdar://12594152

llvm-svn: 188594

Teach the generic instruction selection helper functions to constrain
the register classes of their input operands. For non-physical register
references, the generic code needs to be careful not to mess that up
when replacing references to result registers. As the comment indicates
for MachineRegisterInfo::replaceRegWith(), it's important to call
constrainRegClass() first.

rdar://12594152

llvm-svn: 188593