llvm-svn: 83950

llvm-svn: 83949

for a null pointer.  In other words, "&&foo != NULL" will always work out to
true.

llvm-svn: 83948

more places in clang codegen now.

llvm-svn: 83947

llvm-svn: 83945

llvm-svn: 83943

llvm-svn: 83942

llvm-svn: 83941

about the reason, rdar://7186119.

llvm-svn: 83940

previously we only recognized it on inputs.

llvm-svn: 83939

llvm-svn: 83938

llvm-svn: 83937

llvm-svn: 83936

llvm-svn: 83935

llvm-svn: 83934

llvm-svn: 83933

llvm-svn: 83932

Memory dependence analysis was incorrectly stopping to scan for stores to a pointer at bitcast uses of a malloc call.
It should continue scanning until the malloc call, and this patch fixes that.

llvm-svn: 83931

llvm-svn: 83930

Disable tests that check debug info intrinsic. This does not work if debug info intrinsics are not used to encode debug info.

llvm-svn: 83929

llvm-svn: 83928

llvm-svn: 83925

llvm-svn: 83924

that the scope in which it is being declared is complete. Also, when
instantiating a member class template's ClassTemplateDecl, be sure to
delay type creation so that the resulting type is dependent. Ick.

llvm-svn: 83923

llvm-svn: 83922

llvm-svn: 83921

llvm-svn: 83918

llvm-svn: 83917

before its reference is only supported on ARM has not been true for a while.
In fact, until recently, that was only supported for Thumb.  Besides that,
CPEs are always a multiple of 4 bytes in size, so inserting a CPE should have
no effect on Thumb alignment.

llvm-svn: 83916

should have been a pointer to a reference.

llvm-svn: 83915

llvm-svn: 83914

llvm-svn: 83913

llvm-svn: 83912

that are declarations (rather than definitions). Also, be sure to set
the access specifiers properly when instantiating the declarations of
member function templates.

llvm-svn: 83911

llvm-svn: 83910

llvm-svn: 83908

conditions.  Add a fixit to insert the parentheses.  Also fix a very minor
possible memory leak in 'for' conditions.

Fixes PR 4876 and rdar://problem/7289172

llvm-svn: 83907

llvm-svn: 83905

llvm-svn: 83904

MultiSource/Benchmarks/MiBench/automotive-susan test.  The failure has
since been masked by an unrelated change (just randomly), so I don't have
a testcase for this now.  Radar 7291928.

The situation where this happened is that a constant pool entry (CPE) was
placed at a lower address than the load that referenced it.  There were in
fact 2 CPEs placed at adjacent addresses and referenced by 2 loads that were
close together in the code.  The distance from the loads to the CPEs was
right at the limit of what they could handle, so that only one of the CPEs
could be placed within range.  On every iteration, the first CPE was found
to be out of range, causing a new CPE to be inserted.  The second CPE had
been in range but the newly inserted entry pushed it too far away.  Thus the
second CPE was also replaced by a new entry, which in turn pushed the first
CPE out of range.  Etc.

Judging from some comments in the code, the initial implementation of this
pass did not support CPEs placed _before_ their references.  In the case
where the CPE is placed at a higher address, the key to making the algorithm
terminate is that new CPEs are only inserted at the end of a group of adjacent
CPEs.  This is implemented by removing a basic block from the "WaterList"
once it has been used, and then adding the newly inserted CPE block to the
list so that the next insertion will come after it.  This avoids the ping-pong
effect where CPEs are repeatedly moved to the beginning of a group of
adjacent CPEs.  This does not work when going backwards, however, because the
entries at the end of an adjacent group of CPEs are closer than the CPEs
earlier in the group.

To make this pass terminate, we need to maintain a property that changes can
only happen in some sort of monotonic fashion.  The fix used here is to require
that the CPE for a particular constant pool load can only move to lower
addresses.  This is a very simple change to the code and should not cause
any significant degradation in the results.

llvm-svn: 83902