System z branches have a mask to select which of the 4 CC values should
cause the branch to be taken.  We can invert a branch by inverting the mask.
However, not all instructions can produce all 4 CC values, so inverting
the branch like this can lead to some oddities.  For example, integer
comparisons only produce a CC of 0 (equal), 1 (less) or 2 (greater).
If an integer EQ is reversed to NE before instruction selection,
the branch will test for 1 or 2.  If instead the branch is reversed
after instruction selection (by inverting the mask), it will test for
1, 2 or 3.  Both are correct, but the second isn't really canonical.
This patch therefore keeps track of which CC values are possible
and uses this when inverting a mask.

Although this is mostly cosmestic, it fixes undefined behavior
for the CIJNLH in branch-08.ll.  Another fix would have been
to mask out bit 0 when generating the fused compare and branch,
but the point of this patch is that we shouldn't need to do that
in the first place.

The patch also makes it easier to reuse CC results from other instructions.

llvm-svn: 187495

r187116 moved compare-and-branch generation from the instruction-selection
pass to the peephole optimizer (via optimizeCompare).  It turns out that even
this is a bit too early.  Fused compare-and-branch instructions don't
interact well with predication, where a CC result is needed.  They also
make it harder to reuse the CC side-effects of earlier instructions
(not yet implemented, but the subject of a later patch).

Another problem was that the AnalyzeBranch family of routines weren't
handling compares and branches, so we weren't able to reverse the fused
form in cases where we would reverse a separate branch.  This could have
been fixed by extending AnalyzeBranch, but given the other problems,
I've instead moved the fusing to the long-branch pass, which is also
responsible for the opposite transformation: splitting out-of-range
compares and branches into separate compares and long branches.

I've added a test for the AnalyzeBranch problem.  A test for the
predication problem is included in the next patch, which fixes a bug
in the choice of CC mask.

llvm-svn: 187494

llvm-svn: 187493

r186399 aggressively used the RISBG instruction for immediate ANDs,
both because it can handle some values that AND IMMEDIATE can't,
and because it allows the destination register to be different from
the source.  I realized later while implementing the distinct-ops
support that it would be better to leave the choice up to
convertToThreeAddress() instead.  The AND IMMEDIATE form is shorter
and is less likely to be cracked.

This is a problem for 32-bit ANDs because we assume that all 32-bit
operations will leave the high word untouched, whereas RISBG used in
this way will either clear the high word or copy it from the source
register.  The patch uses the z196 instruction RISBLG for this instead.

This means that z10 will be restricted to NILL, NILH and NILF for
32-bit ANDs, but I think that should be OK for now.  Although we're
using z10 as the base architecture, the optimization work is going
to be focused more on z196 and zEC12.

llvm-svn: 187492

All insertf*/extractf* functions replaced with insert/extract since we have insertf and inserti forms.
Added lowering for INSERT_VECTOR_ELT / EXTRACT_VECTOR_ELT for 512-bit vectors.
Added lowering for EXTRACT/INSERT subvector for 512-bit vectors.
Added a test.

llvm-svn: 187491

The next patch will make use of RISBLG for codegen.

llvm-svn: 187490

is that the command is quoted differently from the arguments. The
command has '\' and the argument has '\\'. This is made unclear because
FileCheck escapes the single matched '\' when it prints the contents of
the variable, thus fooling me into thinking it had matched '\\' as
intended. The solution is to bind the gcc_install variable in the
argument list rather than out of the command. To do so we also have to
be a bit more careful so that we don't get stray other things into the
'.*' regex.

Also, because of the argument difference, '\\\\' is the correct
formulation before crtbegin, go back to that.

llvm-svn: 187489

replacing one variable with the regex. This won't fix anything, but will
hopefully shed light on the nature of the failure.

llvm-svn: 187488

testcase.

llvm-svn: 187487

the path separator used when locating crtbegin.o.

I'll watch the bots to see if there are other issues lurking here.

llvm-svn: 187486

llvm-svn: 187485

llvm-svn: 187484

llvm-svn: 187483

llvm-svn: 187482

Added function for removing relative operators from input paths.

llvm-svn: 187481

the extra check introduces 22 new test failures with the LLDB clang buildbot.

Note that the unhandled DWARF_OP codes in DWARFExpression::Evaluate don't cause test failures if the check is ignored.

llvm-svn: 187480

The heuristic that merges register pressure sets was bogus for ARM's S/D regs.

llvm-svn: 187479

llvm-svn: 187478

llvm-svn: 187477

Changed register names (and pointer keywords) to be lower case when using Intel X86 assembler syntax.

Patch by Richard Mitton.

llvm-svn: 187476

This fix is very lightweight. The same fix already existed for AddRec
but was missing for NAry expressions.

This is obviously an improvement and I'm unsure how to test compile
time problems.

Patch by Xiaoyi Guo!

llvm-svn: 187475

llvm-svn: 187474

list have a shared pointer back to their DisassemblerLLVMC.  This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now.  I'll go back and fix this
for real when I have time to do so.

<rdar://problem/14581918>

llvm-svn: 187473

llvm-svn: 187472

Patch by Richard Mitton.

llvm-svn: 187471

For a testcase like the following:

 typedef unsigned long uint64_t;

 typedef struct {
   uint64_t lo;
   uint64_t hi;
 } blob128_t;

 void add_128_to_128(const blob128_t *in, blob128_t *res) {
   asm ("PAND %1, %0" : "+Q"(*res) : "Q"(*in));
 }

where we'll fail to allocate the register for the output constraint,
our matching input constraint will not find a register to match,
and could try to search past the end of the current operands array.

On the idea that we'd like to attempt to keep compilation going
to find more errors in the module, change the error cases when
we're visiting inline asm IR to return immediately and avoid
trying to create a node in the DAG. This leaves us with only
a single error message per inline asm instruction, but allows us
to safely keep going in the general case.

llvm-svn: 187470

No functionality change.

llvm-svn: 187469

No functionality change.

llvm-svn: 187468

llvm-svn: 187467

Clang when linking and using a GCC installation from a GCC
cross-compiler.

This was desired already by two special case platforms (Android and
Mips), and turns out to be generally (if frustratingly) true. I've added
a substantial comment to the code clarifying the underlying assumptions
of doing actual cross compiles with Clang (or GCC for that matter!) and
help avoid further confusion here.

The end result is to realize that fully general form of PR12478 cannot
be resolved while we support existing cross-compiling GCC toolchains,
and linking with them (namely, linking against their libgcc and
libstdc++ installs). GCC installs these target libraries under
a target-specific prefix but one that may not be available within the
actual sysroot in use. When linking in this world, GCC works and Clang
should as well, but caveat emptor: DSOs from this tree must be
replicated and rpath-fixed to be found at runtime within the sysroot.

I've extended the cross compile test cases to cover these issues by
pointing them at a sysroot and actually checking the library search
paths.

llvm-svn: 187466

change, other than removal of undefined behavior.

llvm-svn: 187465

One form would accept a vector of pointers, and the other did not.
Make both accept vectors of pointers, and add an assertion
for the number of elements.

llvm-svn: 187464

The unix one was returning no_such_file_or_directory, but the windows one
was return success.

Update the one one caller that was depending on the old behavior.

llvm-svn: 187463

llvm-svn: 187462

llvm-svn: 187461

llvm-svn: 187460

llvm-svn: 187459

Before:
  template <typename... Types>
        typename enable_if < 0<sizeof...(Types)>::type Foo() {}
After:
  template <typename... Types>
  typename enable_if<0 < sizeof...(Types)>::type Foo() {}

llvm-svn: 187458

llvm-svn: 187457

llvm-svn: 187456