my last patch to this file.

The issue there was that all uses of an IV inside a loop
are actually references to Base[IV*2], and there was one
use outside that was the same but LSR didn't see the base
or the scaling because it didn't recurse into uses outside
the loop; thus, it used base+IV*scale mode inside the loop
instead of pulling base out of the loop.  This was extra bad
because register pressure later forced both base and IV into
memory.  Doing that recursion, at least enough
to figure out addressing modes, is a good idea in general;
the change in AddUsersIfInteresting does this.  However,
there were side effects....

It is also possible for recursing outside the loop to
introduce another IV where there was only 1 before (if
the refs inside are not scaled and the ref outside is).
I don't think this is a common case, but it's in the testsuite.
It is right to be very aggressive about getting rid of
such introduced IVs (CheckForIVReuse and the handling of
nonzero RewriteFactor in StrengthReduceStridedIVUsers).
In the testcase in question the new IV produced this way
has both a nonconstant stride and a nonzero base, neither
of which was handled before.  (This patch does not handle 
all the cases where this can happen.)  And when inserting 
new code that feeds into a PHI, it's right to put such 
code at the original location rather than in the PHI's 
immediate predecessor(s) when the original location is outside 
the loop (a case that couldn't happen before)
(RewriteInstructionToUseNewBase); better to avoid making
multiple copies of it in this case.

Everything above is exercised in
CodeGen/X86/lsr-negative-stride.ll (and ifcvt4 in ARM which is
the same IR).

llvm-svn: 61178

and safe and orthogonal from turning off load pre.

llvm-svn: 61177

llvm-svn: 61176

llvm-svn: 61175

llvm-svn: 61174

llvm-svn: 61173

Rewrite PTHLexer::DiscardToEndOfLine() to not use GetToken and instead only read the bytes needed to determine if a token is not at the start of the line.

llvm-svn: 61172

llvm-svn: 61171

Change PTHLexer::getSourceLocation() to not call GetToken() and instead just read the file offset in the token data buffer directly.

llvm-svn: 61170

with everyone's favorite error messages:

Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
Bootstrap comparison failure!
./c-decl.o differs
./cp/decl.o differs
./df-core.o differs
./gcc.o differs
./i386.o differs
./stor-layout.o differs
./tree-pretty-print.o differs
./tree.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2

See PR3227.

llvm-svn: 61169

PTHLexer::isNextPPTokenLParen() no longer calls GetToken() and just reads the token kind from the token data buffer.  This results in a minor speedup and reduces the dependency on GetToken().

llvm-svn: 61168

XFAIL for now.

llvm-svn: 61167

llvm-svn: 61166

Delay semantic analysis of the C++ names casts when the subexpression is type-dependent or the destination type is dependent.

llvm-svn: 61165

Today the front-ends (llvm-gcc and clang) generate multiple llvm.dbg.compile_units to identify source file for various debug entities. Each llvm.dbg.compile_unit matches one file on the disk. However, the backend only supports one DW_TAG_compile_unit per .o file. The backend selects first compile_unit from the vector to construct DW_TAG_compile_unit entry, which is not correct in all cases.

First step to resolve this is, record file name and directory directly in debug info for various debug entities. 

llvm-svn: 61164

fix a few more memory leaks: clean the ASTRecordLayouts, ASTObjCInterfaces and ASTRecordForInterface maps

llvm-svn: 61163

commit r61160).

llvm-svn: 61162

(which will pass duplicate-ivar-check.m test again).

llvm-svn: 61161

llvm-svn: 61160

llvm-svn: 61159

llvm-svn: 61158

- Fix regression reported in <rdar://problem/6452745>.  After a null check, null references to resources should not have a retain count.  This regression was caused by removing the call to "GRTransferFuncs::EvalAssume" in BasicConstraintManager.
- Added a test case to test this behavior.

llvm-svn: 61155

Note that one test duplicate-ivar-check.m will fail because I 
need to re-implement duplicate ivar checking.

llvm-svn: 61154

- ability to insert previously created instructions using a builder
- creation of aliases
- creation of inline asm constants

Patch by Zoltan Varga!

llvm-svn: 61153

llvm-svn: 61152

llvm-svn: 61151

llvm-svn: 61150

- Because of the introduction of AnonTypedRegions when reasoning about casts, we
  had a regression in the "symbolication" of variable values passed-by-reference
  to a function. This is now fixed in CFRefCount.cpp (-checker-cfref) by
  blasting through the layer of AnonTypedRegions when symbolicating the value of
  the variable. This logic may get moved elsewhere. Note that this change
  affects only -checker-cfref and not -checker-simple; eventually this logic
  should get pulled out of CFRefCount.cpp into a more common place. All users
  use -checker-cfref by default, and -checker-simple should probably just be
  removed.  
- Updated test 'Analysis/uninit-vals-ps.c' to only use -checker-cfref and added
  a test case for this regression.

llvm-svn: 61147

llvm-svn: 61146

llvm-svn: 61145

llvm-svn: 61144

llvm-svn: 61143

always-current SVN version.

llvm-svn: 61142

Improved on property diagnostics.
Added a FIXME per Steve's comments.

llvm-svn: 61141

Make the injected-class-name of a C++ class a separate RecordDecl from the class itself, with a different scope. This eliminates some ownership issues, so that the RecordDecl only lives in a single context

llvm-svn: 61140

llvm-svn: 61139

llvm-svn: 61138

  warning: statement was disambiguated as declaration

because it is currently firing in cases where the declaration would
not actually parse as a statement. We'd love to bring this warning
back if we can make it more accurate.

llvm-svn: 61137

llvm-svn: 61135

Fix <rdar://problem/6450964> clang on xcode: Assertion failed: (RecordForDecl && "lookupFieldDeclForIvar no storage for class").

This was a recent regression caused by r61043 (related to code gen. for ivar references).

Fariborz, please review. I have some other concerns related to code generation for ivars that we can discuss later.

llvm-svn: 61134