llvm-svn: 134734

Found by valgrind.

llvm-svn: 134733

llvm-svn: 134732

llvm-svn: 134731

llvm-svn: 134730

llvm-svn: 134729

Fix up dependency file name printing to more closely match that of gcc, including fixing a nasty recent regression that could make us print "/foo.h" with a command-line including "-I ./".

rdar://problem/9734352

llvm-svn: 134728

Fix a FIXME.

llvm-svn: 134727

llvm-svn: 134725

llvm-svn: 134721

llvm-svn: 134720

llvm-svn: 134719

llvm-svn: 134717

recursive function.

Also fixed ClangASTContext::IsPointerType to correctly NULL out the pointee
handle if a valid one is provided.

llvm-svn: 134715

No functional change.

llvm-svn: 134714

TableGen'erated MC lowering pseudo-expansion.

llvm-svn: 134712

llvm-svn: 134709

llvm-svn: 134708

llvm-svn: 134707

object to a __weak object type. // rdar://9732636

llvm-svn: 134706

Hook up the TableGen lowering for simple pseudo instructions for ARM and
use it for a subset of the many pseudos the backend has as proof of concept.

More conversions to come.

llvm-svn: 134705

This allows the (many) pseudo-instructions we have that map onto a single
real instruction to have their expansion during MC lowering handled
automatically instead of the current cumbersome manual expansion required.
These sorts of pseudos are common when an instruction is used in situations
that require different MachineInstr flags (isTerminator, isBranch, et. al.)
than the generic instruction description has. For example, using a move
to the PC to implement a branch.

llvm-svn: 134704

llvm-svn: 134703

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