This problem was found and fixed by José Fonseca in March 2011 for
SmallPtrSet, committed r128566.  But as far as I can tell, all other
llvm hash tables retain the same problem:  the bucket count can grow
without bound while size() remains near constant by repeated
insert/erase cycles that tend to fill the container with tombstones. 
Here is a demo that has been reduced to a trivial case:

int
main()
{
   llvm::DenseSet<unsigned> d;
   for (unsigned i = 0; i < 0xFFFFFFF; ++i)
   {
       d.insert(i);
       d.erase(i);
   }
}

While the container size() never grows above 1, the bucket count grows
like this:

nb = 64
nb = 128
nb = 256
nb = 512
nb = 1024
nb = 2048
nb = 4096
nb = 8192
nb = 16384
nb = 32768
nb = 65536
nb = 131072
nb = 262144
nb = 524288
nb = 1048576
nb = 2097152
nb = 4194304
nb = 8388608
nb = 16777216
nb = 33554432
nb = 67108864
nb = 134217728
nb = 268435456

The above program currently consumes a few GB ram.  This patch brings
the memory consumption down by several orders of magnitude, and keeps
the bucket count at 64 for the above test.

llvm-svn: 193689

The PowerPC and ARM native builders spotted this.

llvm-svn: 193688

This required correcting the definition of the bins[lr]i intrinsics because
the result is also the first operand.

It also required removing the (arbitrary) check for 32-bit immediates in
MipsSEDAGToDAGISel::selectVSplat().

Currently using binsli.d with 2 bits set in the mask doesn't select binsli.d
because the constant is legalized into a ConstantPool. Similar things can
happen with binsri.d with more than 10 bits set in the mask. The resulting
code when this happens is correct but not optimal.

llvm-svn: 193687

llvm-svn: 193686

It's possible to embed the frontend in applications that haven't initialized
backend targets so we need to handle this condition gracefully.

llvm-svn: 193685

Before:
  if (a) {
    f();
  }
      // or else ..
      else {
    g();
  }

After:
  if (a) {
    f();
  }
  // or else ..
  else {
    g();
  }

llvm-svn: 193684

Before (clang-format wouldn't change):
  #include  "a.h"
  #include<a>

After:
  #include "a.h"
  #include <a>

This fixes llvm.org/PR16151.

llvm-svn: 193683

(or (and $a, $mask), (and $b, $inverse_mask)) => (vselect $mask, $a, $b).
where $mask is a constant splat. This allows bitwise operations to make use
of bsel.

It's also a stepping stone towards matching bins[lr], and bins[lr]i from
normal IR.

Two sets of similar tests have been added in this commit. The bsel_* functions
test the case where binsri cannot be used. The binsr_*_i functions will
start to use the binsri instruction in the next commit.

llvm-svn: 193682

No test since -debug output is intended for developers and not end-users.

llvm-svn: 193681

splat.d is implemented but this subtest is currently disabled. This is because
it is difficult to match the appropriate IR on MIPS32. There is a patch under
review that should help with this so I hope to enable the subtest soon.

llvm-svn: 193680

Make thunk this/return adjustment ABI-specific. Also, fix the return adjustment when using -cxx-abi microsoft

Reviewed at http://llvm-reviews.chandlerc.com/D2026

llvm-svn: 193679

Patch by Christopher Olsen. Thank you!

llvm-svn: 193678

Now Hexagon and SystemZ are not happy with it :-(

llvm-svn: 193677

The Type Legalizer recognizes that VSELECT needs to be split, because the type
is to wide for the given target. The same does not always apply to SETCC,
because less space is required to encode the result of a comparison. As a result
VSELECT is split and SETCC is unrolled into scalar comparisons.

This commit fixes the issue by checking for VSELECT-SETCC patterns in the DAG
Combiner. If a matching pattern is found, then the result mask of SETCC is
promoted to the expected vector mask type for the given target. This mask has
usually the same size as the VSELECT return type (except for Intel KNL). Now the
type legalizer will split both VSELECT and SETCC.

This allows the following X86 DAG Combine code to sucessfully detect the MIN/MAX
pattern. This fixes PR16695, PR17002, and <rdar://problem/14594431>.

Reviewed by Nadav

llvm-svn: 193676

llvm-svn: 193675

llvm-svn: 193674

llvm-svn: 193673

Differential Revision: http://llvm-reviews.chandlerc.com/D2057

llvm-svn: 193672

scope, be careful about function-scope declarations (which are not declared in
their semantic context).

llvm-svn: 193671

llvm-svn: 193670

  s!//<!///<!

llvm-svn: 193669

llvm-svn: 193668

llvm-svn: 193667

CFNumberRef is toll-free bridged to NSNumber
We can use the same summary formatter for both types

llvm-svn: 193666

llvm-svn: 193665

llvm-svn: 193664

One of the things that dynamic typing affects is the count of children a type has
Clear out the flag that makes us blindly believe the children count when a dynamic type change is detected

llvm-svn: 193663

llvm-svn: 193662

!= 0

llvm-svn: 193661

Use EmitLabelOffsetDifference for handling on darwin platform when
non-darwin platforms use EmitLabelPlusOffset.

Also fix a bug in EmitLabelOffsetDifference where the size is hard-coded
to 4 even though Size is passed in as an argument.

llvm-svn: 193660

Fix a crasher that would occur if one tried to read memory as characters of some size != 1, e.g.
x -f c -s 10  buffer

This commit tries to do the right thing and uses the byte-size as the number of elements, unless both are specified and the number of elements is != 1
In this latter case (e.g. x -f c -s 10 -c 3  buffer) one could multiply the two and read 30 characters, but it seems a stretch in mind reading.

llvm-svn: 193659

To support ref_addr, we calculate the section offset of a DIE (i.e. offset
of a DIE from beginning of the debug info section). The Offset field in DIE
is currently CU-relative. To calculate the section offset, we add a
DebugInfoOffset field in CompileUnit to store the offset of a CU from beginning
of the debug info section. We set the value in DwarfUnits::computeSizeAndOffset
for each CompileUnit.

A helper function DIE::getCompileUnit is added to return the CU DIE that
the input DIE belongs to. We also add a map CUDieMap in DwarfDebug to help
finding the CU for a given CU DIE.

For a cross-referenced DIE, we first find the CU DIE it belongs to with
getCompileUnit, then we use CUDieMap to get the corresponding CU for the CU DIE.
Adding the section offset of the CU with the CU-relative offset of a DIE gives
us the seciton offset of the DIE.

We correctly emit ref_addr with relocation using EmitLabelPlusOffset when
doesDwarfUseRelocationsAcrossSections is true.

This commit handles the emission of DW_FORM_ref_addr when we have an attribute
with FORM_ref_addr. A follow-on patch will start using ref_addr when adding a
DIEEntry. This commit will be tested and verified in the follow-on patch.

Reviewed off-list by Eric, Thanks.

llvm-svn: 193658

after the DIE creation, we construct the context first.

Ensure that we create the context before we create a type so that we can add
the newly created type to the parent. Remove last use of addToContextOwner
now that it's not needed.

We use createAndAddDIE to wrap around "new DIE(". Now all shareable DIEs
should be added to their parents right after the creation.

Reviewed off-list by Eric, Thanks.

llvm-svn: 193657

Helper functions are added:
emitPostLd: emit a post-increment load operation with given size.
emitPostSt: emit a post-increment store operation with given size.

No functionality change.

llvm-svn: 193656

llvm-svn: 193655

Patch by Qin Zhao.

llvm-svn: 193654

This modifies the pass to classify every SSP-triggering AllocaInst according to
an SSPLayoutKind (LargeArray, SmallArray, AddrOf).  This analysis is collected
by the pass and made available for use, but no other pass uses it yet.

The next patch will make use of this analysis in PEI and StackSlot
passes.  The end goal is to support ssp-strong stack layout rules.

WIP.

Differential Revision: http://llvm-reviews.chandlerc.com/D1789

llvm-svn: 193653

When constructing a scop sometimes the exact representation of a statement or
condition would be very complex, but there is a common case which is a lot
simpler, but which is only valid under certain assumptions. The assumed context
records the assumptions taken during the construction of this scop and that need
to be code generated as a run-time test.

At the moment, we do not yet model any assumptions, but only added the
AssumedContext as well as the isl-ast generation support. As a next step,
this needs to be hooked up with the isl code generation.

if (1) /* run-time condition */
  {  /* optimized code */ }
else
  {  /* original code */ }

llvm-svn: 193652

llvm-svn: 193651

Use 32-bit types for the array instead of 64. This should
generally be better anyway.

In optimized + assert builds, I saw a failure when a
cond code / type combination that is never set was loading
a non-zero value and hitting the != Promote assert.

It turns out when loading the 64-bit value to do the shift,
the assembly loads the 2 32-bit halves from non-consecutive
addresses. The address the second half of the loaded uint64_t
doesn't include the offset of the array in the struct. Instead
of being offset + 4, it's just + 4.

I'm not entirely sure why this wasn't observed before.
setCondCodeAction isn't heavily used by the in-tree targets,
and not with the higher valued vector SimpleValueTypes. Only
PPC is using one of the > 32 valued types, and that is probably
never used by anyone on a 32-bit MSVC compiled host.

I ran into this when upgrading LLVM versions, so I guess the
value loaded from the nonsense address happened to work out
before.

No test since I'm not really sure if / how it can be reproduced
with the current in tree targets, and it's not supposed to change
anything.

llvm-svn: 193650