result_type is no longer part of the type traits, so keeping it here
is confusing.

llvm-svn: 234044

llvm-svn: 234043

The plan here is to push the API changes out from the common components
(like Constant::getGetElementPtr and IRBuilder::CreateGEP related
functions) and just update callers to either pass the type if it's
obvious, or pass null.

Do this with LoadInst as well and anything else that comes up, then to
start porting specific uses to not pass null anymore - this may require
some refactoring in each case.

llvm-svn: 234042

Differential Revision: http://reviews.llvm.org/D8596

llvm-svn: 234041

No functional changes.

llvm-svn: 234040

What we are doing in ELFTarget.h was dubious. In the file, we define
partial classes of <Arch>LinkingContexts to declare only static member
functions. We have different (complete) class definitions in other files.
They would conflict if they exist in the same compilation unit (because
the ones defined in ELFTarget.h has only static member functions).
I don't think this was valid C++.

http://reviews.llvm.org/D8797

llvm-svn: 234039

As a follow-up to r234021, assert that a debug info intrinsic variable's
`MDLocalVariable::getInlinedAt()` always matches the
`MDLocation::getInlinedAt()` of its `!dbg` attachment.

The goal here is to get rid of `MDLocalVariable::getInlinedAt()`
entirely (PR22778), but I'll let these assertions bake for a while
first.

If you have an out-of-tree backend that just broke, you're probably
attaching the wrong `DebugLoc` to a `DBG_VALUE` instruction.  The one
you want is the location that was attached to the corresponding
`@llvm.dbg.declare` or `@llvm.dbg.value` call that you started with.

llvm-svn: 234038

llvm-svn: 234037

This avoids crashing or corrupting data if multiple concurrent
processes write to the same .gcda file. This is hard to test, since
the previous behaviour was a data race that often worked out, and it
ignores errors in flock to fall back to the old racy behaviour so that
it won't degrade the behaviour on filesystems that don't support
flock.

llvm-svn: 234036

llvm-svn: 234034

C structs.

This comes up when we have a function that takes a struct and is defined in a
C++ file and used in a C file.

Before this commit, we will generate byval for C++ and will expand the struct
for C, thus causing difference at IR level. We will use bitcast of function type
at the callsite, which causes the inliner to not inline the function.

This commit changes how we handle small C like structs at IR level, but at
backend, we should generate the same argument passing before and after the
commit.

Note that the condition for expanding is still over conservative. We should be
able to expand type that is spelled with “class” and types that are not C-like.
But this commit fixes the inconsistent argument passing between C/C++.

Reviewed by John.

rdar://20121030

llvm-svn: 234033

llvm-svn: 234032

Most desktop environments let the users specify his preferred application per
file type. On mac/linux we can use open/xdg-open for that and should try this
first before starting a heuristic search for various programs.

Differential Revision: http://reviews.llvm.org/D6534

llvm-svn: 234031

This patch fixes the swig generation scripts to use os.path.join
instead, which produces correctly normalized paths for platforms
that don't use the standard forward slash separator.

llvm-svn: 234030

llvm-svn: 234029

because the OS X builders aren't happy with them.

<rdar://problem/20416388>

llvm-svn: 234028

llvm-svn: 234027

Use `MDLocalVariable` and `MDExpression` directly for the arguments of
`EmitFuncArgumentDbgValue()` to simplify a follow-up patch.

llvm-svn: 234026

llvm-svn: 234025

llvm-svn: 234024

Fixed that.

llvm-svn: 234023

remove redundant and unnecessary test parameters

llvm-svn: 234022

Check that the `MDLocalVariable::getInlinedAt()` in a debug info
intrinsic's variable always matches the `MDLocation::getInlinedAt()` of
its `!dbg` attachment.

The goal here is to get rid of `MDLocalVariable::getInlinedAt()`
entirely (PR22778), since it's expensive and unnecessary, but I'll let
this verifier check bake for a while (a week maybe?) first.  I've
updated the testcases that had the wrong value for `inlinedAt:`.

This checks that things are sane in the IR, but currently things go out
of whack in a few places in the backend.  I'll follow shortly with
assertions in the backend (with code fixes).

If you have out-of-tree testcases that just started failing, here's how
I updated these ones:

 1. The verifier check gives you the basic block, function, instruction,
    and relevant metadata arguments (metadata numbering doesn't
    necessarily match the source file, unfortunately).
 2. Look at the `@llvm.dbg.*()` instruction, and compare the
    `inlinedAt:` fields of the variable argument (second `metadata`
    argument) and the `!dbg` attachment.
 3. Figure out based on the variable `scope:` chain and the functions in
    the file whether the variable has been inlined (and into what), so
    you can determine which `inlinedAt:` is actually correct.  In all of
    the in-tree testcases, the `!MDLocation()` was correct and the
    `!MDLocalVariable()` was wrong, but YMMV.
 4. Duplicate the metadata that you're going to change, and add/drop the
    `inlinedAt:` field from one of them.  Be careful that the other
    references to the same metadata node point at the correct one.

llvm-svn: 234021

llvm-svn: 234020

Grab the `MDLocalVariable` from the second-to-last argument; the last
argument is an `MDExpression`, and mixing them up will crash.

llvm-svn: 234019

NFC.

llvm-svn: 234018

llvm-svn: 234017

verifying that the types from that module don't
override types from DWARF.  Also added a target setting
to LLDB so we can tell Clang where to look for these
local modules.

<rdar://problem/18805055>

llvm-svn: 234016

Missing vector tests for rL233482

llvm-svn: 234015

llvm-svn: 234014

llvm-svn: 234013

When enabling PPC64LE, I disabled some optimizations of BUILD_VECTOR
nodes for little endian because wrong results were produced.  I've
subsequently investigated and found this is due to a call to
BuildVectorSDNode::isConstantSplat that was always specifying
big-endian.  With this changed to correctly identify the target
endianness, the optimizations work as expected.

I found another case of a call to the same method with big-endian
hardcoded, in PPC::isAllNegativeZeroVector().  I discovered this was
an orphaned method with no callers, so I've just removed it.

The existing test/CodeGen/PowerPC/vec_constants.ll checks these
optimizations, so for testing I've just added a variant for little
endian.

llvm-svn: 234011

Address space is a lot more constrained on 32-bit Android compared to Linux.

llvm-svn: 234010

This patch provides implementation of R_ARM_TARGET1 relocation with
configuration of its behaviour from a command line. This patch provides
two command line options for GnuLd driver: --arm-target1-rel and
--arm-target1-abs (similar to ld option names with extra prefix 'arm-').
So user may choose which behaviour of R_ARM_TARGET1 is preferred for his
implementation of libc.

Differential Revision: http://reviews.llvm.org/D8707

llvm-svn: 234009

llvm-svn: 234008

llvm-svn: 234007

llvm-svn: 234006

llvm-svn: 234005

This patch attempts to fold the shuffling of 'scalar source' inputs - BUILD_VECTOR and SCALAR_TO_VECTOR nodes - if the shuffle node is the only user. This folds away a lot of unnecessary shuffle nodes, and allows quite a bit of constant folding that was being missed.

Differential Revision: http://reviews.llvm.org/D8516

llvm-svn: 234004

This typo was introduced as part of http://reviews.llvm.org/D8760

llvm-svn: 234003