llvm-svn: 66870

for i32/i64 expressions (we could also do i16 on cpus where
i16 lea is fast, but I didn't add this).  On the example, we now
generate:

_test:
	movl	4(%esp), %eax
	cmpl	$42, (%eax)
	setl	%al
	movzbl	%al, %eax
	leal	4(%eax,%eax,8), %eax
	ret

instead of:

_test:
	movl	4(%esp), %eax
	cmpl	$41, (%eax)
	movl	$4, %ecx
	movl	$13, %eax
	cmovg	%ecx, %eax
	ret

llvm-svn: 66869

example to:

_test:
	movl	4(%esp), %eax
	cmpl	$41, (%eax)
	setg	%al
	movzbl	%al, %eax
	orl	$4294967294, %eax
	ret

instead of:

        movl    4(%esp), %eax
        cmpl    $41, (%eax)
	movl	$4294967294, %ecx
	movl	$4294967295, %eax
	cmova	%ecx, %eax
	ret

which is smaller in code size and faster. rdar://6668608

llvm-svn: 66868

llvm-svn: 66867

llvm-svn: 66866

operands can't both be fully folded at the same time. For example,
in the included testcase, a global variable is being added with
an add of two values. The global variable wants RIP-relative
addressing, so it can't share the address with another base
register, but it's still possible to fold the initial add.

llvm-svn: 66865

defaults to off.  When enabled, it emits range info along
with the file/line/col information for a diagnostic.  This
allows tools that textually parse the output of clang to know
where the ranges are, even if they span multiple lines.  For 
example, with:

$ clang exprs.c -fprint-source-range-info

We now produce:

exprs.c:21:11:{21:12-21:13}: warning: use of unary operator that may be intended as compound assignment (+=)
      var =+ 5;  // expected-warning {{use of unary operator that may be intended as compound assignment (+=)}}
          ^~
exprs.c:22:11:{22:12-22:13}: warning: use of unary operator that may be intended as compound assignment (-=)
      var =- 5;  // expected-warning {{use of unary operator that may be intended as compound assignment (-=)}}
          ^~
exprs.c:36:13:{36:3-36:12}: error: assignment to cast is illegal, lvalue casts are not supported
  (float*)X = P;   // expected-error {{assignment to cast is illegal, lvalue casts are not supported}}
  ~~~~~~~~~ ^
exprs.c:41:4:{41:3-41:4}: error: called object type 'int' is not a function or function pointer
  X();  // expected-error {{called object type 'int' is not a function or function pointer}}
  ~^
exprs.c:45:15:{45:8-45:14}{45:17-45:24}: error: invalid operands to binary expression ('int *' and '_Complex float')
   P = (P-42) + Gamma*4;  // expected-error {{invalid operands to binary expression ('int *' and '_Complex float')}}
       ~~~~~~ ^ ~~~~~~~
exprs.c:61:7:{61:16-61:22}: error: invalid application of '__alignof' to bitfield
  R = __alignof(P->x);  // expected-error {{invalid application of '__alignof' to bitfield}} expected-warning {{extension used}}
      ^        ~~~~~~

Note the range info after the column in the initial diagnostic.

This is obviously really annoying if you're not a tool parsing the 
output of clang, which is why it is off by default.

llvm-svn: 66862

llvm-svn: 66860

codegen (speculative execution).

llvm-svn: 66859

llvm-svn: 66858

Also, add some FIXMEs, improve doxygen & comments.

llvm-svn: 66857

llvm-svn: 66856

llvm-svn: 66855

source being a non-pointer.

llvm-svn: 66854

llvm-svn: 66853

C++ templates. In particular, keep track of the overloaded operators
that are visible from the template definition, so that they can be
merged with those operators visible via argument-dependent lookup at
instantiation time. 

Refactored the lookup routines for argument-dependent lookup and for
operator name lookup, so they can be called without immediately adding
the results to an overload set.

Instantiation of these expressions is completely wrong. I'll work on
that next.

llvm-svn: 66851

llvm-svn: 66850

include the triplet so that people that run multiple targets in
parallel, say i386 and x86_64 can distinguish between the two.

llvm-svn: 66849

print-{multi-{directory,lib,os-directory}, search-dirs} as unsupported
instead of handling separately.

llvm-svn: 66848

to the stack.  This shrinks all llvm tools by 9k, and improves reentrancy.

llvm-svn: 66847

llvm-svn: 66846

llvm-svn: 66845

llvm-svn: 66844

llvm-svn: 66843

ExplodedGraph::TrimGraph:
- Just do a DFS both ways instead of BFS-DFS. We're just determining what subset
  of the nodes are reachable from the root and reverse-reachable from the bug
  nodes.  DFS is more efficient for this task.
  
BugReporter:
- MakeReportGraph: Do a reverse-BFS instead of a reverse-DFS to determine the
  approximate shortest path through the simulation graph. We were seeing some
  weird cases where too many loops were being reported for simple bugs. Possibly
  we will need to replace this with actually computing the shortest path in
  terms of line numbers.

llvm-svn: 66842

right; did the wrong thing when there are exactly 11
non-debug instructions, followed by debug info.
Remove a FIXME since it's apparently been fixed along the way.

llvm-svn: 66840

llvm-svn: 66839

llvm-svn: 66838

llvm-svn: 66837

bitmap generation for basic ivars seem to
work now. This is work in progress.

llvm-svn: 66836

llvm-svn: 66835

the selector for the property setter.

llvm-svn: 66834

Store the type of the integral value within a TemplateArgument, so that we can more efficiently reconstruct an IntegerLiteral from it during template instantiation

llvm-svn: 66833

Fix crash when using TypedViewRegions and ObjCQualifiedIdTypes (TypedViewRegion::getLValueType() was not implemented).

llvm-svn: 66830

single character writes.

llvm-svn: 66827

in the Ada testcase.  Reverting this only covers up
the real problem, which is a nasty conceptual difficulty
in the phi elimination pass: when eliminating phi nodes
in landing pads, the register copies need to come before
the invoke, not at the end of the basic block which is
too late...  See PR3784.

llvm-svn: 66826

llvm-svn: 66825

sorting of ConstantInt's; unreinvent wheel.

llvm-svn: 66824

refers to the "prefix" directory, i.e., one level above "bin".  LLVMGCCPATH
is used as the directory containing the llvm-gcc executable, so add a "/bin"
suffix to get from LLVMGCCDIR to LLVMGCCPATH.

llvm-svn: 66823

llvm-svn: 66820