| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
for this. Reported by Timur Iskhodzhanov.
llvm-svn: 157583
|
| |
|
|
|
|
| |
Clients may define the __asan_default_options char string containing the default options for the tool now.
llvm-svn: 157582
|
| |
|
|
|
|
|
|
|
| |
Attribute bits above 1<<30 are now encoded correctly. Additionally,
the encoding/decoding functionality has been hoisted to helper functions
in Attributes.h in an effort to help the encoding/decoding to stay in
sync with the Attribute bitcode definitions.
llvm-svn: 157581
|
| |
|
|
| |
llvm-svn: 157580
|
| |
|
|
| |
llvm-svn: 157579
|
| |
|
|
| |
llvm-svn: 157578
|
| |
|
|
| |
llvm-svn: 157577
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implemented IntItem - the wrapper around APInt. Why not to use APInt item directly right now?
1. It will very difficult to implement case ranges as series of small patches. We got several large and heavy patches. Each patch will about 90-120 kb. If you replace ConstantInt with APInt in SwitchInst you will need to changes at the same time all Readers,Writers and absolutely all passes that uses SwitchInst.
2. We can implement APInt pool inside and save memory space. E.g. we use several switches that works with 256 bit items (switch on signatures, or strings). We can avoid value duplicates in this case.
3. IntItem can be easyly easily replaced with APInt.
4. Currenly we can interpret IntItem both as ConstantInt and as APInt. It allows to provide SwitchInst methods that works with ConstantInt for non-updated passes.
Why I need it right now? Currently I need to update SimplifyCFG pass (EqualityComparisons). I need to work with APInts directly a lot, so peaces of code
ConstantInt *V = ...;
if (V->getValue().ugt(AnotherV->getValue()) {
...
}
will look awful. Much more better this way:
IntItem V = ConstantIntVal->getValue();
if (AnotherV < V) {
}
Of course any reviews are welcome.
P.S.: I'm also going to rename ConstantRangesSet to IntegersSubset, and CRSBuilder to IntegersSubsetMapping (allows to map individual subsets of integers to the BasicBlocks).
Since in future these classes will founded on APInt, it will possible to use them in more generic ways.
llvm-svn: 157576
|
| |
|
|
|
|
| |
the end of SwitchInst.
llvm-svn: 157575
|
| |
|
|
|
|
| |
the first 'n' directories from the filename.
llvm-svn: 157574
|
| |
|
|
| |
llvm-svn: 157573
|
| |
|
|
|
|
|
| |
we can't open the file even after creating all of the directories to it, then
just give up.
llvm-svn: 157572
|
| |
|
|
|
|
|
| |
* Check for absolute paths before using the GCOV_PREFIX.
* Don't add an ending path separator if there's already one.
llvm-svn: 157571
|
| |
|
|
| |
llvm-svn: 157570
|
| |
|
|
| |
llvm-svn: 157569
|
| |
|
|
| |
llvm-svn: 157568
|
| |
|
|
| |
llvm-svn: 157567
|
| |
|
|
| |
llvm-svn: 157566
|
| |
|
|
| |
llvm-svn: 157565
|
| |
|
|
|
|
|
|
| |
replicating the code for every place it's needed, we instead generate a function
that does that for us. This function is local to the executable, so there
shouldn't be any writing violations.
llvm-svn: 157564
|
| |
|
|
| |
llvm-svn: 157562
|
| |
|
|
| |
llvm-svn: 157561
|
| |
|
|
| |
llvm-svn: 157560
|
| |
|
|
| |
llvm-svn: 157559
|
| |
|
|
| |
llvm-svn: 157557
|
| |
|
|
| |
llvm-svn: 157556
|
| |
|
|
| |
llvm-svn: 157555
|
| |
|
|
| |
llvm-svn: 157554
|
| |
|
|
|
|
|
|
|
|
| |
instantiatiating a template.
This comes up in the begin/end calls of a range-for (see the included test
case). Other suggestions are welcome, though this seems to do the trick without
regressing anything.
llvm-svn: 157553
|
| |
|
|
|
|
| |
as zeroes. Now the digits are properly non-zero.
llvm-svn: 157552
|
| |
|
|
| |
llvm-svn: 157551
|
| |
|
|
| |
llvm-svn: 157550
|
| |
|
|
|
|
|
| |
The DenseMap reallocates after 64 insertions so this only happened in
large test cases under very specific circumstances.
llvm-svn: 157549
|
| |
|
|
|
|
| |
type's size.
llvm-svn: 157548
|
| |
|
|
|
|
|
|
| |
bitwidth and signedness. Also rename the variable to reflect its purpose.
No test case - discovered during random code exploration.
llvm-svn: 157547
|
| |
|
|
|
|
| |
when using rvalue refs.
llvm-svn: 157546
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Intrinsic::getDefinition,
making it stronger and more sane.
Delete the code from tblgen that produced the old code.
Besides being a path forward in intrinsic sanity, this also eliminates a bunch of
machine generated code that was compiled into Function.o
llvm-svn: 157545
|
| |
|
|
|
|
|
|
|
| |
because
the old verifier just checked that something "was a pointer", but not that the pointee
was correct.
llvm-svn: 157544
|
| |
|
|
|
|
| |
by the new intrinsic verifier.
llvm-svn: 157543
|
| |
|
|
| |
llvm-svn: 157542
|
| |
|
|
|
|
|
|
|
| |
definition in the map before calling itself to retrieve the
DIE for the declaration. Without this change, if this causes
getOrCreateSubprogramDIE to be recursively called on the definition,
it will create multiple DIEs for that definition. Fixes PR12831.
llvm-svn: 157541
|
| |
|
|
|
|
| |
info table.
llvm-svn: 157540
|
| |
|
|
|
|
|
|
|
|
| |
FindAndConstruct.
The only missing part is insert(), which uses a pair of parameters and I haven't
figured out how to convert it to rvalue references. It's now possible to use a
DenseMap with std::unique_ptr values :)
llvm-svn: 157539
|
| |
|
|
| |
llvm-svn: 157538
|
| |
|
|
|
|
| |
to the declaration in this patch. // rdar://10893232
llvm-svn: 157537
|
| |
|
|
|
|
|
| |
it is (at the cost of 45 bytes of extra table space) so that the verifier can
start using it.
llvm-svn: 157536
|
| |
|
|
|
|
|
| |
These tend to be copied around a lot, moving it instead saves a ton of memory
accesses.
llvm-svn: 157535
|
| |
|
|
|
|
| |
Retain + Release on a ref counted pointer is cheap, but not free (it adds a function call in this case).
llvm-svn: 157534
|
| |
|
|
| |
llvm-svn: 157533
|
| |
|
|
|
|
| |
While there make it a SmallPtrSet.
llvm-svn: 157532
|