llvm-svn: 157615

llvm-svn: 157614

llvm-svn: 157613

llvm-svn: 157612

which will contain code shared between asan and tsan run-times.

Naming is hard. If you can suggest a better name for the directory -- speak up.

llvm-svn: 157611

llvm-svn: 157608

Store a pointer to each ScopStmt in the isl_id associated with the space of its
domain. This will later allow us to recover the statement during code
generation with isl.

llvm-svn: 157607

In general, all code that we produce is NSW.

llvm-svn: 157606

We will reuse this function for the isl code generator.

llvm-svn: 157605

llvm-svn: 157604

llvm-svn: 157603

Leave a better fixme for different debug info flags

llvm-svn: 157602

is negligible, but it makes the code clearer. Based on a suggestion by
Jordy Rose.

llvm-svn: 157601

llvm-svn: 157600

llvm-svn: 157599

native_log2.  Patch by Joshua Cranmer!

llvm-svn: 157598

llvm-svn: 157597

the operands are vectors of doubles.

llvm-svn: 157596

llvm-svn: 157595

llvm-svn: 157594

llvm-svn: 157593

llvm-svn: 157592

llvm-svn: 157591

llvm-svn: 157590

llvm-svn: 157589

Use actual factory functions rather than derived classes acting as named constructors/factories.

llvm-svn: 157588

The test case feeds the following into InstCombine's visitSelect:
%tobool8 = icmp ne i32 0, 0
%phitmp = select i1 %tobool8, i32 3, i32 0
Then instcombine replaces the right side of the switch with 0, doesn't notice
that nothing changes and tries again indefinitely.

This fixes PR12897.

llvm-svn: 157587

llvm-svn: 157586

llvm-svn: 157585

llvm-svn: 157584

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

llvm-svn: 157575

Add support for the GCOV_PREFIX_STRIP env variable which tries to strip off the first 'n' directories from the filename.

llvm-svn: 157574