- Oct 30, 2013
-
-
Howard Hinnant authored
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
-
Alp Toker authored
The PowerPC and ARM native builders spotted this. llvm-svn: 193688
-
Daniel Sanders authored
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
-
Alp Toker authored
llvm-svn: 193686
-
Alp Toker authored
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
-
Daniel Jasper authored
Before: if (a) { f(); } // or else .. else { g(); } After: if (a) { f(); } // or else .. else { g(); } llvm-svn: 193684
-
Daniel Jasper authored
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
-
Daniel Sanders authored
(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
-
Daniel Sanders authored
No test since -debug output is intended for developers and not end-users. llvm-svn: 193681
-
Daniel Sanders authored
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
-
Timur Iskhodzhanov authored
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
-
Daniel Jasper authored
Patch by Christopher Olsen. Thank you! llvm-svn: 193678
-
Juergen Ributzka authored
Now Hexagon and SystemZ are not happy with it :-( llvm-svn: 193677
-
Juergen Ributzka authored
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
-
Bill Wendling authored
llvm-svn: 193675
-
Akira Hatanaka authored
llvm-svn: 193674
-
Akira Hatanaka authored
llvm-svn: 193673
-
Josh Magee authored
Differential Revision: http://llvm-reviews.chandlerc.com/D2057 llvm-svn: 193672
-
Richard Smith authored
scope, be careful about function-scope declarations (which are not declared in their semantic context). llvm-svn: 193671
-
Evgeniy Stepanov authored
llvm-svn: 193670
-
NAKAMURA Takumi authored
s!//<!///<! llvm-svn: 193669
-
NAKAMURA Takumi authored
llvm-svn: 193668
-
Evgeniy Stepanov authored
llvm-svn: 193667
-
rdar://problem/15143022Enrico Granata authored
CFNumberRef is toll-free bridged to NSNumber We can use the same summary formatter for both types llvm-svn: 193666
-
Warren Hunt authored
llvm-svn: 193665
-
Warren Hunt authored
llvm-svn: 193664
-
rdar://problem/15045059Enrico Granata authored
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
-
Michael J. Spencer authored
llvm-svn: 193662
-
Warren Hunt authored
!= 0 llvm-svn: 193661
-
Manman Ren authored
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
-
rdar://problem/15296388Enrico Granata authored
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
-
- Oct 29, 2013
-
-
Manman Ren authored
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
-
Manman Ren authored
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
-
Manman Ren authored
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
-
Evgeniy Stepanov authored
llvm-svn: 193655
-
Evgeniy Stepanov authored
Patch by Qin Zhao. llvm-svn: 193654
-
Josh Magee authored
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
-
Tobias Grosser authored
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
-
Matt Arsenault authored
llvm-svn: 193651
-
Matt Arsenault authored
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
-