llvm-svn: 226004

[Hexagon] Deleting versions of compare-not that don't have encoding information.  Updating references.

llvm-svn: 226003

llvm-svn: 225991

Use unwind.h to get the declarations for unwinding interfaces.  This header is
already provided by clang and gcc, so this adds no additional dependencies for
building the builtins library.  It avoids the duplication which may drift over
time though.

llvm-svn: 225990

This helps us avoid 'invalid register class for operand' verifier
errors.

llvm-svn: 225989

llvm-svn: 225988

llvm-svn: 225987

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

llvm-svn: 225986

llvm-svn: 225985

Override the TLI callback enableAggressiveFMAFusion and return true. Indeed, fmul, fmadd and fadd nodes cost the same number of cycles, so we can enable more combining heuristics to produce more fmadd nodes.

llvm-svn: 225984

This can happen if:
* It is present in a comdat in one file.
* It is not present in the comdat of the file that is kept.
* Is is not used.

This should fix the LTO boostrap.

Thanks to Takumi NAKAMURA for setting up the bot!

llvm-svn: 225983

Disable AlwaysBreakBeforeMultilineString, as the style guides don't
really say to do so.

llvm-svn: 225982

Summary:
This fixes MultiSource/Applications/lemon on big-endian N32 by correcting the
handling of the argument to wait(). glibc defines it as a transparent union of
void* and int*. Such unions are passed according to the rules of the first
member so the argument must be passed as if it were a void* (sign extended from
i32 to i64) and not as a union (shifted to the upper bits of an i64).

wait() already behaves correctly on big-endian O32 and N64 since the union is
already the same size as an argument slot.

Reviewers: atanasyan

Reviewed By: atanasyan

Subscribers: cfe-commits

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

llvm-svn: 225981

llvm-svn: 225980

Sorry for the noise, I managed to miss a bunch of recent regressions of
include orderings here. This should actually sort all the includes for
Clang. Again, no functionality changed, this is just a mechanical
cleanup that I try to run periodically to keep the #include lines as
regular as possible across the project.

llvm-svn: 225979

This is just a mechanical cleanup, no functionality changed. This just
fixes very minor inconsistencies with how #include lines were spaced and
sorted in LLD.

llvm-svn: 225978

This speeds up the dependency calculations for blocks with many load/store/call instructions.
Beside the improved runtime, there is no functional change.

Compared to the original commit, this re-applied commit contains a bug fix which ensures that there are
no incorrect collisions in the alias cache.

llvm-svn: 225977

No functionality changed, this is just a mechanical cleanup to keep the
order of #include lines consistent across the project.

llvm-svn: 225976

No functionality changed, this is a purely mechanical cleanup to ensure
the #include order remains consistent across the project.

llvm-svn: 225975

utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.

llvm-svn: 225974

Before:
  try
    (SomeResource rs = someFunction()) {
      Something();
    }

After:
  try (SomeResource rs = someFunction()) {
    Something();
  }

llvm-svn: 225973

llvm-svn: 225972

Before:
  boolean someFunction(@Param(aaaaaaaaaaaaaaaa)
                       String aaaaa,
      String bbbbbbbbbbbbbbb) {}

After:
  boolean someFunction(
      @Param(aaaaaaaaaaaaaaaa) String aaaaa,
      String bbbbbbbbbbbbbbb) {}

llvm-svn: 225971

Now that the passes are wrappers around this, we no longer need
a vtable, virtual destructor, and other associated mess. This is
particularly nice to me as this is a class template. =]

llvm-svn: 225970

This adds the domtree analysis to the new pass manager. The analysis
returns the same DominatorTree result entity used by the old pass
manager and essentially all of the code is shared. We just have
different boilerplate for running and printing the analysis.

I've converted one test to run in both modes just to make sure this is
exercised while both are live in the tree.

llvm-svn: 225969

This commit refines the pattern for the octeon seq/seqi/sne/snei instructions.
The target register is set to 0 or 1 according to the result of the comparison.
In C, this is something like

rd = (unsigned long)(rs == rt)

This commit adds a zext to bring the result to i64. With this change the
instruction is selected for this type of code. (gcc produces the same code for
the above C code.)

llvm-svn: 225968

llvm-svn: 225967

into the new pass manager's analysis cache which stores results
by-value.

Technically speaking, the dom trees were originally not movable but
copyable! This, unsurprisingly, didn't work at all -- the copy was
shallow and just resulted in rampant memory corruption. This change
explicitly forbids copying (as it would need to be a deep copy) and
makes them explicitly movable with the unsurprising boiler plate to
member-wise move them because we can't rely on MSVC to generate this
code for us. =/

llvm-svn: 225966

llvm-svn: 225965

Before:
  @Test
  ReturnType
  doSomething(String aaaaaaaaaaaaa, String bbbbbbbbbbbbbbb) {}

After:
  @Test
  ReturnType doSomething(
      String aaaaaaaaaaaaa, String bbbbbbbbbbbbbbb) {}

llvm-svn: 225964

Before:
  @SomeAnnotation
  (aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa)
  int i;

After:
  @SomeAnnotation(
      aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa)
  int i;

llvm-svn: 225963

Before:
  @Test(a)
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaa(
      aaaaaaaaaaaaaaaaaaaaaaa);

After:
  @Test(a)
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa =
      aaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaa);

llvm-svn: 225962

llvm-svn: 225961

llvm-svn: 225960

llvm-svn: 225959

llvm-svn: 225958

llvm-svn: 225957

Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits).

Several pieces of code were relying on implicit debug location setting
which usually lead to incorrect line information anyway. So I've fixed
those (in r225955 and r225845) separately which should pave the way for
this commit to be cleanly reapplied.

The reason these implicit dependencies resulted in crashes with this
patch is that the debug location would no longer implicitly leak from
one place to another, but be set back to invalid. Once a call with
no/invalid location was emitted, if that call was ever inlined it could
produce invalid debugloc chains and assert during LLVM's codegen.

There may be further cases of such bugs in this patch - they're hard to
flush out with regression testing, so I'll keep an eye out for reports
and investigate/fix them ASAP if they come up.

Original commit message:

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: 225956

Without setting the CurEHLocation these cleanups would be attributed to
whatever the last active debug line location was (the 'fn' call in the
included test cases). By setting CurEHLocation correctly the line
information is improved/corrected.

This quality bug turned into a crasher with r225000 when, instead of
allowing the last location to persist, it would be zero'd out. This
could lead to a function call (such as the dtor) being made without a
debug location - if that call was subsequently inlined (and the caller
and callee had debug info, just not the call instruction) the inliner
would violate important constraints about the debug location chains by
not updating the inlined instructions to chain up to the callee
locations.

So, by fixing this bug, I am addressing the assertion failures
introduced by r225000 and should be able to recommit that patch with
impunity...

llvm-svn: 225955

The buildbots got upset after r225941, this should hopefully fix things.

llvm-svn: 225954