[SROA] Add a test case for r225068 / PR22080.

llvm-svn: 225070

[SROA] Fix the loop exit placement to be prior to indexing the splits
array. This prevents it from walking out of bounds on the splits array.

Bug found with the existing tests by ASan and by the MSVC debug build.

llvm-svn: 225069

[SROA] Fix two total think-os in r225061 that should have been caught on
a +asserts bootstrap, but my bootstrap had asserts off. Oops.

Anyways, in some places it is reasonable to cast (as a sanity check) the
pointer operand to a load or store to an instruction within SROA --
namely when the pointer operand is expected to be derived from an
alloca, and thus always an instruction. However, the pre-splitting code
also deals with loads and stores to non-alloca pointers and there we
need to just use the Value*. Nothing about the code relied on the
instruction cast, it was only there essentially as an invariant
assertion. Remove the two that don't actually hold.

This should fix the proximate issue in PR22080, but I'm also doing an
asserts bootstrap myself to see if there are other issues lurking.

I'll craft a reduced test case in a moment, but I wanted to get the tree
healthy as quickly as possible.

llvm-svn: 225068

Drop all constant scheduling dimensions

Schedule dimensions that have the same constant value accross all statements do
not carry any information, but due to the increased dimensionality of the
schedule cost compile time. To not pay this cost, we remove constant dimensions
if possible.

llvm-svn: 225067

[PowerPC] use UINT64_C instead of ul

Attempting to fix PR22078 (building on 32-bit systems) by replacing my careless
use of 1ul to be a uint64_t constant with UINT64_C(1).

llvm-svn: 225066

Revert "Just use a using directive in SmallMapVector instead of inheriting from MapVector itself."

This reverts commit r225059. I think MSVC 2012 has a problem with this. This is
an attempt to fix one of the MSVC 2012 bots.

llvm-svn: 225065

Revert r225053: Add an ArrayRef upcasting constructor from ArrayRef<U*> -> ArrayRef<T*> where T is a base of U.

This appears to have broken at least the windows build bots due to
compile errors in the predicate that didn't simply supress the overload.
I'm not sure what the fix is, and the bots have been broken for a long
time now so I'm just reverting until Michael can figure out a fix.

llvm-svn: 225064

[SROA] Switch to using a more direct debug logging technique in one part
of my new load and store splitting, and fix a bug where it logged
a totally irrelevant slice rather than the actual slice in question.

The logging here previously worked because we used to place new slices
onto the back of the core sequence, but that caused other problems.
I updated the actual code to store new slices in their own vector but
didn't update the logging. There isn't a good way to reuse the logging
any more, and frankly it wasn't needed. We can directly log this bit
more easily.

llvm-svn: 225063

[SROA] Fix formatting with clang-format which I managed to fail to do
prior to committing r225061. Sorry for that.

llvm-svn: 225062

[SROA] Teach SROA how to much more intelligently handle split loads and
stores.

When there are accesses to an entire alloca with an integer
load or store as well as accesses to small pieces of the alloca, SROA
splits up the large integer accesses. In order to do that, it uses bit
math to merge the small accesses into large integers. While this is
effective, it produces insane IR that can cause significant problems in
the rest of the optimizer:

- It can cause load and store mismatches with GVN on the non-alloca side
  where we end up loading an i64 (or some such) rather than loading
  specific elements that are stored.
- We can't always get rid of the integer bit math, which is why we can't
  always fix the loads and stores to work well with GVN.
- This is especially bad when we have operations that mix poorly with
  integer bit math such as floating point operations.
- It will block things like the vectorizer which might be able to handle
  the scalar stores that underly the aggregate.

At the same time, we can't just directly split up these loads and stores
in all cases. If there is actual integer arithmetic involved on the
values, then using integer bit math is actually the perfect lowering
because we can often combine it heavily with the surrounding math.

The solution this patch provides is to find places where SROA is
partitioning aggregates into small elements, and look for splittable
loads and stores that it can split all the way to some other adjacent
load and store. These are uniformly the cases where failing to split the
loads and stores hurts the optimizer that I have seen, and I've looked
extensively at the code produced both from more and less aggressive
approaches to this problem.

However, it is quite tricky to actually do this in SROA. We may have
loads and stores to the same alloca, or other complex patterns that are
hard to handle. This complexity leads to the somewhat subtle algorithm
implemented here. We have to do this entire process as a separate pass
over the partitioning of the alloca, and split up all of the loads prior
to splitting the stores so that we can handle safely the cases of
overlapping, including partially overlapping, loads and stores to the
same alloca. We also have to reconstitute the post-split slice
configuration so we can avoid iterating again over all the alloca uses
(the slow part of SROA). But we also have to ensure that when we split
up loads and stores to *other* allocas, we *do* re-iterate over them in
SROA to adapt to the more refined partitioning now required.

With this, I actually think we can fix a long-standing TODO in SROA
where I avoided splitting as many loads and stores as probably should be
splittable. This limitation historically mitigated the fallout of all
the bad things mentioned above. Now that we have more intelligent
handling, I plan to remove the FIXME and more aggressively mark integer
loads and stores as splittable. I'll do that in a follow-up patch to
help with bisecting any fallout.

The net result of this change should be more fine-grained and accurate
scalars being formed out of aggregates. At the very least, Clang now
generates perfect code for this high-level test case using
std::complex<float>:

  #include <complex>

  void g1(std::complex<float> &x, float a, float b) {
    x += std::complex<float>(a, b);
  }
  void g2(std::complex<float> &x, float a, float b) {
    x -= std::complex<float>(a, b);
  }

  void foo(const std::complex<float> &x, float a, float b,
           std::complex<float> &x1, std::complex<float> &x2) {
    std::complex<float> l1 = x;
    g1(l1, a, b);
    std::complex<float> l2 = x;
    g2(l2, a, b);
    x1 = l1;
    x2 = l2;
  }

This code isn't just hypothetical either. It was reduced out of the hot
inner loops of essentially every part of the Eigen math library when
using std::complex<float>. Those loops would consistently and
pervasively hop between the floating point unit and the integer unit due
to bit math extraction and insertion of floating point values that were
"stored" in a 64-bit integer register around the loop backedge.

So far, this change has passed a bootstrap and I have done some other
testing and so far, no issues. That doesn't mean there won't be though,
so I'll be prepared to help with any fallout. If you performance swings
in particular, please let me know. I'm very curious what all the impact
of this change will be. Stay tuned for the follow-up to also split more
integer loads and stores.

llvm-svn: 225061

CodeGen: Don't crash when a lambda uses a local constexpr variable

The DeclRefExpr might be for a variable initialized by a constant
expression which hasn't been ODR used.
Emit the initializer for the variable instead of trying to capture the
variable itself.

This fixes PR22071.

llvm-svn: 225060

Just use a using directive in SmallMapVector instead of inheriting from MapVector itself.

llvm-svn: 225059

test: fix tests/buildbots

Correct the yaml definition for the object.  Adjust the symbol storage class
which was flipped for the two symbols, resulting in the link failure due to the
symbol missing.  Adjust the virtual address of the section.  This ripples into
the test case, since the data has been shifted up by 4 bytes.

llvm-svn: 225058

ReaderWriter: teach the writer about IMAGE_REL_ARM_ADDR32

This implements the IMAGE_REL_ARM_ADDR32 relocation.  There are still a few more
relocation types that need to resolved before lld can even attempt to link a
trivial program for Windows on ARM.

llvm-svn: 225057

[PowerPC] Improve instruction selection bit-permuting operations (64-bit)

This is the second installment of improvements to instruction selection for "bit
permutation" instruction sequences. r224318 added logic for instruction
selection for 32-bit bit permutation sequences, and this adds lowering for
64-bit sequences. The 64-bit sequences are more complicated than the 32-bit
ones because:
  a) the 64-bit versions of the 32-bit rotate-and-mask instructions
     work by replicating the lower 32-bits of the value-to-be-rotated into the
     upper 32 bits -- and integrating this into the cost modeling for the various
     bit group operations is non-trivial
  b) unlike the 32-bit instructions in 32-bit mode, the rotate-and-mask instructions
     cannot, in one instruction, specify the
     mask starting index, the mask ending index, and the rotation factor. Also,
     forming arbitrary 64-bit constants is more complicated than in 32-bit mode
     because the number of instructions necessary is value dependent.

Plus, support for 'late masking' was added: it is sometimes more efficient to
treat the overall value as if it had no mandatory zero bits when planning the
bit-group insertions, and then mask them in at the very end. Unfortunately, as
the structure of the bit groups is different in the two cases, the more
feasible implementation technique was to generate both instruction sequences,
and then pick the shorter one.

And finally, we now generate reasonable code for i64 bswap:

        rldicl 5, 3, 16, 0
        rldicl 4, 3, 8, 0
        rldicl 6, 3, 24, 0
        rldimi 4, 5, 8, 48
        rldicl 5, 3, 32, 0
        rldimi 4, 6, 16, 40
        rldicl 6, 3, 48, 0
        rldimi 4, 5, 24, 32
        rldicl 5, 3, 56, 0
        rldimi 4, 6, 40, 16
        rldimi 4, 5, 48, 8
        rldimi 4, 3, 56, 0

vs. what we used to produce:

        li 4, 255
        rldicl 5, 3, 24, 40
        rldicl 6, 3, 40, 24
        rldicl 7, 3, 56, 8
        sldi 8, 3, 8
        sldi 10, 3, 24
        sldi 12, 3, 40
        rldicl 0, 3, 8, 56
        sldi 9, 4, 32
        sldi 11, 4, 40
        sldi 4, 4, 48
        andi. 5, 5, 65280
        andis. 6, 6, 255
        andis. 7, 7, 65280
        sldi 3, 3, 56
        and 8, 8, 9
        and 4, 12, 4
        and 9, 10, 11
        or 6, 7, 6
        or 5, 5, 0
        or 3, 3, 4
        or 7, 9, 8
        or 4, 6, 5
        or 3, 3, 7
        or 3, 3, 4

which is 12 instructions, instead of 25, and seems optimal (at least in terms
of code size).

llvm-svn: 225056

Add 2x constructors for TinyPtrVector, one that takes in one elemenet and the other that takes in an ArrayRef<EltTy>

Currently one can only construct an empty TinyPtrVector. These are just missing
elements of the API.

llvm-svn: 225055

Add a SmallMapVector class that is a MapVector with a Map of SmallDenseMap and a Vector of SmallVector.

llvm-svn: 225054

Add an ArrayRef upcasting constructor from ArrayRef<U*> -> ArrayRef<T*> where T is a base of U.

llvm-svn: 225053

ReaderWriter: teach PE/COFF backend about ARM NT

This teaches lld about the ARM NT object types.  Add a trivial test to ensure
that it can handle ARM NT object file inputs.  It is still unable to perform the
necessary relocations for ARM NT, but this allows the linker to at least read
the objects.

llvm-svn: 225052

XFAIL test on win32 due to missing __complex support

llvm-svn: 225051

InstCombine: fsub nsz 0, X ==> fsub nsz -0.0, X

Some day the backend may handle instruction-level fast math flags and make
this transform unnecessary, but it's still better practice to use the canonical
representation of fneg when possible (use a -0.0).

This is a partial fix for PR20870 ( http://llvm.org/bugs/show_bug.cgi?id=20870 ).
See also http://reviews.llvm.org/D6723.

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

llvm-svn: 225050

Avoid building compiler-rt with LTO.

During a LTO we still need to build a compiler_rt with regular object files
in the .a.

llvm-svn: 225049

Add r224985 back with a fix.

The issues was that AArch64 has additional restrictions on when local
relocations can be used. We have to take those into consideration when
deciding to put a L symbol in the symbol table or not.

Original message:

Remove doesSectionRequireSymbols.

In an assembly expression like

bar:
.long L0 + 1

the intended semantics is that bar will contain a pointer one byte past L0.

In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.

The solution used in ELF to use relocation with symbols if there is a non-zero
addend.

In MachO before this patch we would just keep all symbols in some sections.

This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.

This patch implements the non-zero addend logic for MachO too.

llvm-svn: 225048

Reverting 225045 and 225043 and XFAIL multiline.ll on hexagon

llvm-svn: 225047

Add a test for the recent compiler-rt build failure.

llvm-svn: 225046

[Hexagon] Removing assertion to appease buildbot until I can reproduce the problem

llvm-svn: 225045

Revert "Remove doesSectionRequireSymbols."

This reverts commit r224985.

I am investigating why it made an Apple bot unhappy.

llvm-svn: 225044

[Hexagon] Changing an llvm_unreachable to an assertion and returning 0.  Relocations aren't implemented yet but we don't need to abort for this in release builds.

llvm-svn: 225043

r600: get_work_dim: Update metadata syntax for LLVM 3.6

llvm-svn: 225042

Require LLVM 3.6 and bump version to 0.1.0

Some functions are implemented using hand-written LLVM IR, and
LLVM assembly format is allowed to change between versions, so we
should require a specific version of LLVM.

llvm-svn: 225041

[analyzer] Include a couple more comments on using xcrun to query the SDK.

llvm-svn: 225039

[analyzer] Change ccc-analyzer to mimick behavior on OSX Mavericks/Yosemite to automatically infer the SDK location.

llvm-svn: 225038

[X86] Update disassembler tests for absolute move instructions to check the encodings. This provides testing for r225036. 64-bit mode is still broken.

llvm-svn: 225037

[X86] Fix disassembly of absolute moves to work correctly in 16 and 32-bit modes with all 4 combinations of OpSize and AdSize prefixes being present or not.

llvm-svn: 225036

[x86] Simplify detection of jcxz/jecxz/jrcxz in disassembler.

llvm-svn: 225035

InstCombine: try to transform A-B < 0 into A < B

We are allowed to move the 'B' to the right hand side if we an prove
there is no signed overflow and if the comparison itself is signed.

llvm-svn: 225034

[llgo] Elide alloca for unused received values in select

Summary: If a receive case in a select statement is not assigned to a named variable, then we can eliminate the alloca and copy at runtime.

Test Plan: lit test added

Reviewers: pcc

Reviewed By: pcc

Subscribers: llvm-commits

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

llvm-svn: 225033

Revert "merge consecutive stores of extracted vector elements"

This reverts commit r224611. This change causes crashes
in X86 DAG->DAG Instruction Selection.

llvm-svn: 225031

irgen: modify the ABI to use init guards instead of priority

The new ABI is simpler for use cases such as dynamically loaded packages.

The calling convention for import functions is similar to what go/ssa would
produce if BareInits were cleared. However, simply clearing this flag causes
two additional issues:

 1) We would need to special case the 'init$guard' variable (see
    discussion in https://codereview.appspot.com/78780043/).

 2) The call to __go_register_gc_roots needs to appear in the right
    place, i.e. after the guard check. Making this check appear
    in the right place with non-bare inits seems unreliable at best.

So we keep BareInits set and generate the necessary code manually.

It is still possible to get the old ABI by specifying a path to a gccgo
installation.

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

llvm-svn: 225030

irgen: make it possible to use a custom importer

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

llvm-svn: 225029

irgen: return a types.Package to the compiler client

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

llvm-svn: 225028

irgen: introduce ManglePackagePath function

This is useful for clients that need to use llgo's mangling of the package
path to look up a specific function within a given package.

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

llvm-svn: 225027

irgen, driver: modify Compiler.Compile to take a FileSet and Files

This change allows clients to generate IR using "files" received from locations
other than the file system. The regular file parser is moved to a new library,
"driver", which is intended to eventually contain much of the logic from
the existing driver.

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

llvm-svn: 225026

[Hexagon] Adding accumulating add/sub, doubleword logic-not variants, doubleword bitfield extract, word parity, accumulating multiplies with saturation.

llvm-svn: 225024

Update the website with information about LLDB on Windows.

This patch updates the list of supported platforms to include
Windows, and also provides some detailed getting started instructions
for building LLDB on Windows.

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

llvm-svn: 225023

Fix HTML formatting and non-conformance.

llvm-svn: 225022

Handle PPC64 return type (signext i32 rather than plain i32) in test case

llvm-svn: 225021

Fix a test case to not depend on asm comment syntax, so as to be portable

Too many different comment characters - instead of trying to account for
them all, instead disable the comments and just check for end-of-line
instead.

llvm-svn: 225020

Generalize even further, for ARM comment syntax (@)

llvm-svn: 225019

[Hexagon] Adding double-logic on predicate instructions.

llvm-svn: 225018

Generalize test case to handle different asm syntax (# or // comments)

llvm-svn: 225017

[asan] fix coverage between fork() and exec(): reinitialize the guards after fork()

llvm-svn: 225016

[Hexagon] Adding newvalue compare and jumps.

llvm-svn: 225015

RTDyldMemoryManager.cpp: Make the reference to __morestack weak.

This fixes the DSO build for now. Eventually we should develop some
other mechanism to make this work correctly with DSOs.

llvm-svn: 225014

Driver: unify compiler-rt component selection

Unify the component handling for compiler-rt.  The components are regularly
named, built up from:

  ${LIBRARY_PREFIX}clang_rt.${component}-${arch}[-${environment}]${LIBRARY_SUFFIX}

Unify the handling for all the various components, into a single path to link
against the various components in a number of places.  This reduces duplication
of the clang_rt library name construction logic.

llvm-svn: 225013

Driver: whitespace

Fixup some whitespace/style issues.  NFC.

llvm-svn: 225012

DebugInfo: Omit is_stmt from line table entries on the same line.

GCC does this for non-zero discriminators and since GCC doesn't produce
column info, that was the only place it comes up there. For LLVM, since
we can emit discriminators and/or column info, it makes more sense to
invert the condition and just test for changes in line number.

This should resolve at least some of the GDB 7.5 test suite failures
created by recent Clang changes that increase the location fidelity
(which, since Clang defaults to including column info on Linux by
default created a bunch of cases that confused GDB).

In theory we could do this better/differently by grouping actual source
statements together in a similar manner to the way lexical scopes are
handled but given that GDB isn't really in a position to consume that (&
users are probably somewhat used to different lines being different
'statements') this seems the safest and cheapest change. (I'm concerned
that doing this 'right' would bloat the debugloc data even further -
something Duncan's working hard to address)

llvm-svn: 225011

[Hexagon] Adding postincrement register newvalue stores.

llvm-svn: 225010

[Hexagon] Removing old newvalue store variants.  Adding postincrement immediate newvalue stores.

llvm-svn: 225009

[mips][microMIPS] Relocate with symbol for micromips symbols
Differential Revision: http://reviews.llvm.org/D6796

llvm-svn: 225008

[Hexagon] Adding indexed store new-value variants.

llvm-svn: 225007

[Hexagon] Adding indexed store of immediates.

llvm-svn: 225006

[Hexagon] Adding indexed stores.

llvm-svn: 225005

Remove a comment that appears a second time 22 lines further down.

llvm-svn: 225004

x86_64: Fix calls to __morestack under the large code model.

Under the large code model, we cannot assume that __morestack lives within
2^31 bytes of the call site, so we cannot use pc-relative addressing. We
cannot perform the call via a temporary register, as the rax register may
be used to store the static chain, and all other suitable registers may be
either callee-save or used for parameter passing. We cannot use the stack
at this point either because __morestack manipulates the stack directly.

To avoid these issues, perform an indirect call via a read-only memory
location containing the address.

This solution is not perfect, as it assumes that the .rodata section
is laid out within 2^31 bytes of each function body, but this seems to
be sufficient for JIT.

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

llvm-svn: 225003

[asan] add flag coverage_pcs. When false, the coverage is not dumped as PCs. Useful e.g. if the user only needs coverage is bitset

llvm-svn: 225002

Reapply debug info changes now that more precise column information is available.

(recommitting as the Clang patch is back in with the latest fix -
hopefully it sticks)

llvm-svn: 225001

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225000

[asan] change _sanitizer_cov_module_init to accept int* instead of int**

llvm-svn: 224999

[COFF] Don't try to add quotes to already quoted linker directives

If a linker directive is already quoted, don't try to quote it again, otherwise it creates a mess.
This pops up in places like:
#pragma comment(linker,"\"/foo bar'\"")

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

llvm-svn: 224998

[Hexagon] Adding reg-reg indexed load forms.

llvm-svn: 224997

Driver: use the canonical library prefix on Windows

Unlike Unices, Windows does not use a library prefix.  Use the traditional
naming scheme even for Windows itanium environments.  This makes the builtins
behave more like the sanitisers as well.

llvm-svn: 224996

Add non-const version getFileSystemOpts() access function.
All the other get*Opts have both versions.

llvm-svn: 224995

The __morestack function is only available on i386 and x86_64 architectures.

llvm-svn: 224994

Make the __morestack function available to the JIT memory manager under Linux.

This function's implementation lives in libgcc, a static library, so we need
to expose it explicitly, like the other such functions.

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

llvm-svn: 224993

[Hexagon] Dropping old combine instructions without encodings.

llvm-svn: 224992

[Hexagon] Adding compare byte/halfword reg-reg/reg-imm forms.  Adding compare to general register reg-imm form.

llvm-svn: 224991

Cleanup lldb-mi test cases.
Following changes were done.
1. Remove the extra line after -exec-run.
2. Remove check for prompt.
3. Remove 'quit' command.

Initial patch was contributed by ki.stfu@gmail.com.

llvm-svn: 224990

[Hexagon] Updating constant extender def, adding alu-not instructions, compare to general register, and inverted compares.

llvm-svn: 224989

Follow-up to r224987: fix a lint warning

llvm-svn: 224988

[ASan/Win] Sort the list of modules when we fail to reserve the shadow memory range

llvm-svn: 224987

Some code improvements in Masked Load/Store.
No functional changes.

llvm-svn: 224986

Remove doesSectionRequireSymbols.

In an assembly expression like

bar:
.long L0 + 1

the intended semantics is that bar will contain a pointer one byte past L0.

In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.

The solution used in ELF to use relocation with symbols if there is a non-zero
addend.

In MachO before this patch we would just keep all symbols in some sections.

This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.

This patch implements the non-zero addend logic for MachO too.

llvm-svn: 224985

reverted prev commit (it was a mistake)

llvm-svn: 224984

v

llvm-svn: 224983

Add a public accessor for GlobalCtors in CodeGenModule

Summary:
In a JIT context it is useful to be able to access the GlobalCtors
and especially clear them once they have been emitted and called.
This adds a public method to be able to access the list.

Subscribers: yaron.keren, cfe-commits

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

llvm-svn: 224982

Add IRBuilder routines for gc.statepoints, gc.results, and gc.relocates

Nothing particularly interesting, just adding infrastructure for use by in tree users and out of tree users.

Note: These were extracted out of a working frontend, but they have not been well tested in isolation.

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

llvm-svn: 224981

Simplify test a bit.

It looks like the original intent was to check which symbols were created.
With macho-dump the sections were being checked just to match which symbol
was in which section.

llvm-objdump prints the section a symbol is in.

llvm-svn: 224980

[OCaml] Fix bitrot in tests.

llvm-svn: 224979

[lit] Make config.llvm_lib_dir available on cmake, too.

The OCaml tests require config.llvm_lib_dir to determine
the OCaml package search path.

llvm-svn: 224978

[OCaml] [cmake] Use LLVM_LIBRARY_DIR instead of LLVM_LIBRARY_OUTPUT_INTDIR.

The latter variable is internal.

Original patch by Ramkumar Ramachandra <artagnon@gmail.com>

llvm-svn: 224977

Testcases for r224939.

llvm-svn: 224976

Driver: unify addClangRT{Linux,Windows}

The differences are pretty superficial:
- .lib vs .a extensions
- whether or not to link (potentially) incorrectly against libgcc_s

llvm-svn: 224975

Don't crash on an invalid trailing return type on a function before a '...'

clang tries to produce a helpful diagnostic for the traiilng '...', but the
code that r216778 added for this doesn't expect an invalid trailing return type.
Add code to explicitly handle this.

Having explicit code for this but not for other things looks a bit strange, but
trailing return types are special in that they have a separate existence bit in
addition to the type (see r158348).

llvm-svn: 224974

Convert test to llvm-readobj. NFC.

llvm-svn: 224973

Revert "UBSan: Teach isDerivedFromAtOffset and findBaseAtOffset about vbases"

This reverts commit r221445. This change leads to false positives
reports from -fsanitize=vptr. See original commit thread for more
details.

llvm-svn: 224972

Semantic tests for memory invalidation at statepoints

These are simply a collection of tests intended to show that information about the contents of gc references in the heap is lost at a statepoint. I've tried to write them so that they don't disallow correct transformations, while still being fairly easy to understand.

p.s. Ideas for additional tests are welcome.

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

llvm-svn: 224971

Revert "DebugInfo: Generalize debug info location handling"

Asserting when building compiler-rt when using a GCC host compiler.
Reverting while I investigate.

This reverts commit r224941.

llvm-svn: 224970

Revert "Reapply debug info changes now that r224385 has been recommitted to clang (in r224941)"

Asserting when building compiler-rt when using a gcc host compiler.
Reverting while I investigate.

This reverts commit r224942.

llvm-svn: 224969

Carry facts about nullness and undef across GC relocation

This change implements four basic optimizations:

    If a relocated value isn't used, it doesn't need to be relocated.
    If the value being relocated is null, relocation doesn't change that. (Technically, this might be collector specific. I don't know of one which it doesn't work for though.)
    If the value being relocated is undef, the relocation is meaningless.
    If the value being relocated was known nonnull, the relocated pointer also isn't null. (Since it points to the same source language object.)

I outlined other planned work in comments.

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

llvm-svn: 224968