llvm-svn: 257856

Yet another wave of buildbot failures (though fewer this time).
I'm only reverting the Verifier changes, as the test cases
will be fine without them as well, and touching them as often
just introduces unnecessary churn.

llvm-svn: 257855

I originally reapplied this in 257550, but had to revert again due to bot
breakage. The only change in this version is to allow either the TypeSize
or the TypeAllocSize of the variable to be the one represented in debug info
(hopefully in the future we can figure out how to encode the difference).
Additionally, several bot failures following r257550, were due to
optimizer bugs now fixed in r257787 and r257795.

r257550 commit message was:

```
The follow extra changes were made to test cases:

Manually making the variable be the actual type instead of a pointer
to avoid pointer-size differences in generic code:

    LLVM :: DebugInfo/Generic/2010-03-24-MemberFn.ll
    LLVM :: DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll
    LLVM :: DebugInfo/Generic/2010-05-03-DisableFramePtr.ll
    LLVM :: DebugInfo/Generic/varargs.ll

Delete sizing information from debug info for the same reason
(but the presence of the pointer was important to the test case):

    LLVM :: DebugInfo/Generic/restrict.ll
    LLVM :: DebugInfo/Generic/tu-composite.ll
    LLVM :: Linker/type-unique-type-array-a.ll
    LLVM :: Linker/type-unique-simple2.ll

Fixing an incorrect DW_OP_deref

    LLVM :: DebugInfo/Generic/2010-05-03-OriginDIE.ll

Fixing a missing DW_OP_deref

    LLVM :: DebugInfo/Generic/incorrect-variable-debugloc.ll

Additionally, clang should no longer complain during bootstrap should no
longer happen after r257534.

The original commit message was:
``
Summary:
Teach the Verifier to make sure that the storage size given to llvm.dbg.declare
or the value size given to llvm.dbg.value agree with what is declared in
DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA).
Additionally this catches a number of common mistakes, such as passing a
pointer when a value was intended or vice versa.

One complication comes from stack coloring which modifies the original IR when
it merges allocas in order to make sure that if AA falls back to the IR it gets
the correct result. However, given this new invariant, indiscriminately
replacing one alloca by a different (differently sized one) is no longer valid.
Fix this by just undefing out any use of the alloca in a dbg.declare in this
case.

Additionally, I had to fix a number of test cases. Of particular note:
- I regenerated dbg-changes-codegen-branch-folding.ll from the given source as
  it was affected by the bug fixed in r256077
- two-cus-from-same-file.ll was changed to avoid having a variable-typed debug
  variable as that would depend on the target, even though this test is
  supposed to be generic
- I had to manually declared size/align for reference type. See also the
  discussion for D14275/r253186.
- fpstack-debuginstr-kill.ll required changing `double` to `long double`
- most others were just a question of adding OP_deref
``

```

llvm-svn: 257850

Summary: Since you cannot call finalizeObject manually through the C-API and other functions from the C-API automatically call it, LLVMRunStaticConstructors should also call it or otherwise you cannot call it without first calling a workaround function (or call any other function from the C-API which implicitly finalizes the object).

Reviewers: dnovillo, spatel, bkramer, deadalnix, joker.eph, echristo, lhames

Subscribers: llvm-commits

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

llvm-svn: 257849

[libFuzzer] use custom stol; also introduce __libfuzzer_is_present so that users can check for its presence.

llvm-svn: 257848

The previous text was hard to understand even for me and I wrote it.  Hopefully the new structure makes it a bit more clear what's going on.  If anyone has word smithing suggestion or clarification questions, please let me know.

llvm-svn: 257847

llvm-svn: 257846

llvm-svn: 257845

Summary:
This pass may modify the Cmp operands. However, the flag reg may be used by both the branch and CSEL.
Modifying CMP will have side effect on CSEL.

Reviewers: t.p.northover

Subscribers: llvm-commits, aemerson, rengolin

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

llvm-svn: 257844

llvm-svn: 257843

llvm-svn: 257840

llvm-svn: 257835

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

llvm-svn: 257832

Autoconf does this in the GetRepositoryPath script, CMake's VersionFromVCS does grab the SVN_REVISION, but doesn't populate the repository URL.

llvm-svn: 257826

Summary:
Before this the Verifier didn't complain if the GlobalVariable
referenced from a DIGlobalVariable was not in fact in the correct
module (it would crash while writing bitcode though). Fix this by
always checking parantage of GlobalValues while walking constant
expressions and changing the DIGlobalVariable visitor to also
visit the constant it contains.

Reviewers: rafael
Differential Revision: http://reviews.llvm.org/D16059

llvm-svn: 257825

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

llvm-svn: 257824

Summary:
We already have the inverse verification that we only use globals
that are defined in this module. This essentially catches the
same mistake, but when verifying the module that contains the
definition.

Reviewers: rafael
Differential Revision: http://reviews.llvm.org/D15272

llvm-svn: 257823

llvm-svn: 257819

classes.

OrcRemoteTargetClient::RCMemoryManager will now register EH frames with the
server automatically. This allows remote-execution of code that uses exceptions.

llvm-svn: 257816

llvm-svn: 257815

I kept forgetting which number is the line delta and which is the code
delta.

llvm-svn: 257813

llvm-svn: 257811

llvm-svn: 257805

llvm-svn: 257804

David Majnemer noticed that it was not obvious what the behavior would
be if B.Offset - A.Offset could not fit in an int.

llvm-svn: 257803

This patch seeds the SLP vectorizer with getelementptr indices. The primary
motivation in doing so is to vectorize gather-like idioms beginning with
consecutive loads (e.g., g[a[0] - b[0]] + g[a[1] - b[1]] + ...). While these
cases could be vectorized with a top-down phase, seeding the existing bottom-up
phase with the index computations avoids the complexity, compile-time, and
phase ordering issues associated with a full top-down pass. Only bundles of
single-index getelementptrs with non-constant differences are considered for
vectorization.

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

llvm-svn: 257800

Rounding up an integer m to a nearest multiple of n where n is a power
of 2 is used very often if you are writing code to emit binary files.
RoundUpToAlignment is a small function to do that. But we found that the
function has a small but annoying issue; the name is a bit too long.
Because it is used quite often, that hurts readability.

This patch is to rename the function. The original name is kept as a
forwarder, so that submitting this patch won't immediately break Clang
and other LLVM projects. Once I update all occurrences of RoundUpToAlignment,
I'll remove the old name entirely.

http://reviews.llvm.org/D16162

llvm-svn: 257799

Thanks to David Blaikie for noticing it.

llvm-svn: 257796

Summary: If SROA creates only one piece (e.g. because the other is not needed),
it still needs to create a bit_piece expression if that bit piece is smaller
than the original size of the alloca.

Reviewers: aprantl

Subscribers: llvm-commits

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

llvm-svn: 257795

Since r230276, we support an improved legalization for f64->f16,
which goes through a temporary f32, improving codegen when
f32->f16 is legal but not f64->f16. This requires unsafe-fp-math.

However, that legalization assumed that the second step, producing
a pseudo-softened f16, had type i16. That's not true on targets
with illegal i16, such as ARM.

Use the initial f64->f16 result type instead.

llvm-svn: 257794

llvm-svn: 257793

Soon it will be responsible for more than line tables.

Reviewers: majnemer

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

llvm-svn: 257792

It's broken. In 3.7 there wasn't a CMake build for test-suite at all,
so we're not losing something we had before.

llvm-svn: 257791

llvm-svn: 257790

Summary: The dbg.declare -> dbg.value conversion did not check which operand of
the store instruction the alloca was passed to. As a result code that stored the
address of an alloca, rather than storing to the alloca, would still trigger
the conversion routine, leading to the insertion of an incorrect dbg.value
intrinsic.

Reviewers: aprantl

Subscribers: llvm-commits

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

llvm-svn: 257787

rdar://problem/22823264

llvm-svn: 257784

Coverage mapping data is not referenced by runtime, and they won't be dumped
into profile data. There is no need to allocate memory for covmap sections.
A good side effect of this change is that the coverage map data won't be mistakenly
 garbage collected by the linker (for Gold linker only, BFD linker has an issue where the a bug is filed).
Tested with clang build with instrumentation and -fcoverage-mapping and linker GC. The size of
 covmap section is ~17.6M so the text segment size will be reduced by this amount with this change.

llvm-svn: 257781

llvm-svn: 257780

llvm-svn: 257778

llvm-svn: 257777