llvm-svn: 134702

lvalue/xvalue/rvalue, rather than just (incorrectly) assuming it's an
lvalue. Fixes PR10285 / <rdar://problem/9743926>.

llvm-svn: 134700

Should fix llvm-gcc selfhost.

llvm-svn: 134699

preprocessor to build up very large CFGs in various shapes that can
produce different algorithmic behavior in CFG-walking code.

llvm-svn: 134698

Previously, despite the names 'enqueue' and 'dequeue', it behaved as
a stack and visited blocks in a LIFO fashion. This interacts badly with
extremely broad CFGs *inside* of a loop (such as a large switch inside
a state machine) where every block updates a different variable.

When encountering such a CFG, the checker visited blocks in essentially
a "depth first" order due to the stack-like behavior of the work list.
Combined with each block updating a different variable, the saturation
logic of the checker caused it to re-traverse blocks [1,N-1] of the
broad CFG inside the loop after traversing block N. These re-traversals
were to propagate the variable values derived from block N. Assuming
approximately the same number of variables as inner blocks exist, the
end result is O(N^2) updates. By making this a queue, we also make the
traversal essentially "breadth-first" across each of the N inner blocks
of the loop. Then all of this state is propagated around to all N inner
blocks of the loop. The result is O(N) updates.

The truth is in the numbers:
Before, gcc.c:   96409 block visits  (max: 61546,   avg: 591)
After,  gcc.c:   69958 block visits  (max: 33090,   avg: 429)
Before, PR10183: 2540494 block vists (max: 2536495, avg: 37360)
After,  PR10183: 137803 block visits (max: 134406,  avg: 2026)

The nearly 20x reduction in work for PR10183 corresponds to a roughly
100x speedup in compile time.

I've tested it on all the code I can get my hands on, and I've seen no
slowdowns due to this change. Where I've collected stats, the ammount of
work done is on average less. I'll also commit shortly some synthetic
test cases useful in analyzing the performance of CFG-based warnings.

Submitting this based on Doug's feedback that post-commit review should
be good. Ted, please review! Hopefully this helps compile times until
then.

llvm-svn: 134697

llvm-svn: 134696

We have to do this in DAGBuilder instead of DAGCombiner, because the exact bit is lost after building.

  struct foo { char x[24]; };
  long bar(struct foo *a, struct foo *b) { return a-b; }
is now compiled into
  movl	4(%esp), %eax
  subl	8(%esp), %eax
  sarl	$3, %eax
  imull	$-1431655765, %eax, %eax
instead of
  movl	4(%esp), %eax
  subl	8(%esp), %eax
  movl	$715827883, %ecx
  imull	%ecx
  movl	%edx, %eax
  shrl	$31, %eax
  sarl	$2, %edx
  addl	%eax, %edx
  movl	%edx, %eax

llvm-svn: 134695

change.

Previously clang was passing the following feature strings to the ARM backend
when CPU is cortex-a8: +neon,-vfp2,-vfp3

This used to work because -vfp2,-vfp3 had no effect after +neon. Now that the
features are controlled by individual bits (with implied hierarchy), the net
effect is all three features will be turned off.

llvm-svn: 134691

- fix a comment.
- Remove an unnecessary { } block.

llvm-svn: 134690

the one process we're interested in, instead of fetching all
of them and only keeping one.

(the old implementation made sense when we were doing the
initial find-this-process-by-pid-or-name by looking through
all the kinfo_procs.)

llvm-svn: 134686

confusing indentations I've seen recently... Just noticed these while
making a change elsewhere.

No functionality changed.

llvm-svn: 134685

Original patch by John Freeman, some style tweaks by me.

llvm-svn: 134683

loaded. It locks onto *-apple-darwin binaries where the binary has
a "__KLD" segment. Soon I will modify the lldb_private::ObjectFile
class to return an executable type which will be an enum with values
something like:
eObjectFileTypeUserExectable,
eObjectFileTypeUserSharedLibrary,
eObjectFileTypeKernelExectable,
eObjectFileTypeKernelSharedLibrary,
eObjectFileTypeObjectFile,
eObjectFileTypeCoreFile

But for now we look at the section since a user and kernel mach-o
executable have the same mach-o file type.

llvm-svn: 134682

process being preferred for all memory reads.

llvm-svn: 134681

llvm-svn: 134680

new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way
changes to the varformats.html document (WIP)

llvm-svn: 134679

- Each target asm parser now creates its own MCSubtatgetInfo (if needed).
- Changed AssemblerPredicate to take subtarget features which tablegen uses
  to generate asm matcher subtarget feature queries. e.g.
  "ModeThumb,FeatureThumb2" is translated to
  "(Bits & ModeThumb) != 0 && (Bits & FeatureThumb2) != 0".

llvm-svn: 134678

Make GVN look through extractvalues for recognised intrinsics. GVN can then CSE ops that match values produced by the intrinsics.

llvm-svn: 134677

llvm-svn: 134675

argument expansion to use the macro argument source locations as well.
Add a few tests to exercise this. There is still a bit more work needed
here though.

llvm-svn: 134674

Right now clang-139 fails the test.

llvm-svn: 134673

be detected yet, but most of the initial code is there and needs to be 
debugged more.

llvm-svn: 134672

llvm-svn: 134671

pointers.  Some of the spots are obviously initialized
later, but it's better just to NULL the pointers out
at initialization to make the code more robust when
exposed to later changes.

llvm-svn: 134670

CommandCompletions.cpp and DataBufferMemoryMap.cpp.  The file type
part of the st_mode struct member is not a bitmask.

llvm-svn: 134669

llvm-svn: 134668

llvm-svn: 134667

It was testing a linear scan feature:

  Test if linearscan is unfavoring registers for allocation to allow
  more reuse of reloads from stack slots.

The greedy register allocator doesn't access any stack slots in this
function, so the linear scan feature was not being tested.

llvm-svn: 134666

Fixes PR9602!

llvm-svn: 134665

processor supports it just fine.

Fixes PR9675 and rdar://9740801

llvm-svn: 134664

llvm-svn: 134663

but we don't have an error message.

llvm-svn: 134662

llvm-svn: 134661

instantiation and improve diagnostics which are stem from macro
arguments to trace the argument itself back through the layers of macro
expansion.

This requires some tricky handling of the source locations, as the
argument appears to be expanded in the opposite direction from the
surrounding macro. This patch provides helper routines that encapsulate
the logic and explain the reasoning behind how we step through macros
during diagnostic printing.

This fixes the rest of the test cases originially in PR9279, and later
split out into PR10214 and PR10215.

There is still some more work we can do here to improve the macro
backtrace, but those will follow as separate patches.

llvm-svn: 134660

The Python API does not need SBEvent::BroadcasterMatchesPtr() when SBEvent::BroadcasterMatchesRef() suffices.

llvm-svn: 134659

llvm-svn: 134658

extra register.

Part of PR10299 and rdar://9740322

llvm-svn: 134657

searching for variables and symbols in the target
more robust.  These checks prevent variables from
being reported as existing if they cannot actually
be evaluated in the current context.

llvm-svn: 134656

object to a __weak object/type. // rdar://9732636.
One item is yet todo.

llvm-svn: 134655

Fixes PR10299 and rdar://9740322

llvm-svn: 134654