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

    
This option takes the name of the basic block you want to visualize
with -view-*-dags

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

llvm-svn: 225953

In case folding a node end up with a NaN as operand for the select, 
the folding of the condition of the selectcc node returns "UNDEF".

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

llvm-svn: 225952

llvm-svn: 225951

If there is no associated immediate (MS style inline asm), do not try to access
the operand, assume that it is valid.  This should fix the buildbots after SVN
r225941.

llvm-svn: 225950

    
When processing an array, every Elt has the same layout, it is
useless to recursively call each ComputeLinearIndex on each element.
Just do it once and multiply by the number of elements.
    
Differential Revision: http://reviews.llvm.org/D6832

llvm-svn: 225949

This reverts commit:
http://reviews.llvm.org/D3392

llvm-svn: 225948

This reverts commit:
http://reviews.llvm.org/D3393

llvm-svn: 225947

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

llvm-svn: 225946

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

llvm-svn: 225945

Copy the `GVMap` over to a standard `ValueToValueMapTy` so that we can
reuse the `MapMetadata()` logic.  Unfortunately the `GVMap` can't just
be replaced, since `MapMetadata()` likes to modify the map, but at least
this will prevent NVPTX from bitrotting.

llvm-svn: 225944

The comment is incorrect, and the code mangles debug info.  Remove the
bad logic, which wasn't tested anyway.

llvm-svn: 225943

llvm-svn: 225942

The int instruction takes as an operand an 8-bit immediate value.  Validate that
the input is valid rather than silently truncating the value.

llvm-svn: 225941

Disable a couple of tests, CodeGen/X86/noop-insert.ll and CodeGen/X86/noop-insert-percentage.ll, in r225908, to unbreak tests.

llvm-svn: 225940

class members are implicitly "inline", no key word needed.

Naturally, this could change how LLVM inlines these functions because
<GRR>, but that's not an excuse to use the keyword. ;]

llvm-svn: 225939

significantly. Clean it up with the help of clang-format.

I've touched this up by hand in a couple of places that weren't quite
right (IMO). I think most of these actually have bugs open about
already.

llvm-svn: 225938

formatted or placed incorrectly.

llvm-svn: 225937

Correct, we have *zero* basic testing of the dominator tree in the
regression test suite. There is a single test that even prints it out,
and that test only checks a single line of the output. There are
a handful of tests that check post dominators, but all of those are
looking for bugs rather than just exercising the basic machinery.

This test is super boring and unexciting. But hey, it's something.
I needed there to be something so I could switch the basic test to run
with both the old and new pass manager.

llvm-svn: 225936

  I.E. more than two -> exactly two
Fix a typo function name in LoopVectorize.
  I.E. collectStrideAcccess() -> collectStrideAccess()

llvm-svn: 225935

We would check the type information from the declaration found by lookup
but we would neglect checking compatibility with the most recent
declaration.  This would make it possible for us to not correctly
diagnose inconsistencies with declarations which were made in a
different scope.

llvm-svn: 225934

llvm-svn: 225933

llvm-svn: 225932

complain that the flag doesn't exist.

llvm-svn: 225931

Somehow we seem to have ended up without any actual tests of the
CodeGen side. Easy enough to fix.

llvm-svn: 225930

llvm-svn: 225929

The form of nops used is CPU-specific (some CPUs, such as the POWER7, have
special group-terminating nops). We probably want a different callback for this
kind of nop insertion (something more like MCAsmBackend::writeNopData), or for
PPC to use a different mechanism for scheduling nops, but this will stop the
test from failing for now.

llvm-svn: 225928

This reduces coverage for Evergreen, since the more
complete tests have those run lines disabled.

llvm-svn: 225927

Don't do the v4i8 -> v4f32 combine if the load will need to
be expanded due to alignment. This stops adding instructions
to repack into a single register that the v_cvt_ubyteN_f32
instructions read.

llvm-svn: 225926

Now that the source and destination types can be specified,
allow doing an expansion that doesn't use an EXTLOAD of the
result type. Try to do a legal extload to an intermediate type
and extend that if possible.

This generalizes the special case custom lowering of extloads
R600 has been using to work around this problem.

This also happens to fix a bug that would incorrectly use more
aligned loads than should be used.

llvm-svn: 225925