multi-library path suffix.

The code calculates MIPS toolchain specific multi-lib path suffixes like
mips16/soft-float/el is moved to the separate function
findMultiLibSuffix(). This function called during GCC installation
detection and result is stored for the future using.

The patch reviewed by Rafael Espindola.
http://llvm-reviews.chandlerc.com/D1738

llvm-svn: 191612

llvm-svn: 191611

llvm-svn: 191610

llvm-svn: 191609

llvm-svn: 191608

llvm-svn: 191607

putting them in the call operator's DeclContext. This better matches the
language wording and avoids some cases where code gets confused by them for
namespace-scope lambdas and the like.

llvm-svn: 191606

and capturing a variable declaration, and complete the implementation of them.

llvm-svn: 191605

llvm-svn: 191604

We were completely ignoring the unorder/ordered attributes of condition
codes and also incorrectly lowering seto and setuo.

Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 191603

SelectionDAG will now attempt to inverse an illegal conditon in order to
find a legal one and if that doesn't work, it will attempt to swap the
operands using the inverted condition.

There are no new test cases for this, but a nubmer of the existing R600
tests hit this path.

llvm-svn: 191602

This is useful for targets like R600, which only support GT, GE, NE, and EQ
condition codes as it removes the need to handle unsupported condition
codes in target specific code.

There are no tests with this commit, but R600 has been updated to take
advantage of this new feature, so its existing selectcc tests are now
testing the swapped operands path.

llvm-svn: 191601

Interpreting the results of this function is not very intuitive, so I
cleaned it up to make it more clear whether or not a SETCC op was
legalized and how it was legalized (either by swapping LHS and RHS or
replacing with AND/OR).

This patch does change functionality in the LHS and RHS swapping case,
but unfortunately there are no in-tree tests for this.  However, this
patch is a prerequisite for R600 to take advantage of the LHS and RHS
swapping, so tests will be added in subsequent commits.

llvm-svn: 191600

...rather than trying to figure it out from the call site, and having
people complain that we guessed wrong and that a prototype-less call is
the same as a variadic call on their system. More importantly, fix a
crash when there's no decl at the call site (though we could have just
returned a default value).

<rdar://problem/15037033>

llvm-svn: 191599

llvm-svn: 191598

llvm-svn: 191597

llvm-svn: 191596

llvm-svn: 191595

llvm-svn: 191594

We treat TBAA tags as struct-path aware TBAA format when the first operand
is a MDNode and the tag has 3 or more operands.

llvm-svn: 191593

llvm-svn: 191592

of loops.

Previously, two consecutive calls to function "func" would result in the
following sequence of instructions:

1. load $16, %got(func)($gp) // load address of lazy-binding stub.
2. move $25, $16
3. jalr $25                  // jump to lazy-binding stub.
4. nop
5. move $25, $16
6. jalr $25                  // jump to lazy-binding stub again.

With this patch, the second call directly jumps to func's address, bypassing
the lazy-binding resolution routine:

1. load $25, %got(func)($gp) // load address of lazy-binding stub.
2. jalr $25                  // jump to lazy-binding stub.
3. nop
4. load $25, %got(func)($gp) // load resolved address of func.
5. jalr $25                  // directly jump to func.

llvm-svn: 191591

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

llvm-svn: 191590

llvm-svn: 191589

closest ISA.  armv6 wouldn't have the handful of
T32 instructions that the Cortex-M0 ISA specifies.
<rdar://problem/15099306> 

llvm-svn: 191588

It uses the T16 and a few T32 instructions from the ARMv7-A ISA.
<rdar://problem/15099306> 

llvm-svn: 191587

Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.

llvm-svn: 191586

llvm-svn: 191585

if property name is a valid identifier in the underlying
language. // rdar://15044184

llvm-svn: 191584

llvm-svn: 191583

llvm-svn: 191582

Stop using some locally defined mach-o constants.

llvm-svn: 191581

llvm-svn: 191580

llvm-svn: 191579

resolved by lazy-binding.

llvm-svn: 191578

tomorrow is complete.

There is a missing warning due to a serious issue with template
instantiation in Clang (and potentially in the core language).

llvm-svn: 191577

llvm-svn: 191576

llvm-svn: 191575

llvm-svn: 191574

llvm-svn: 191573