llvm/lib/Analysis, branch masterhttp://llvm.orghttps://git.amat.us/llvm/atom/lib/Analysis?h=master2013-05-06T02:07:24ZFix unchecked uses of DominatorTree in MemoryDependenceAnalysis.2013-05-06T02:07:24ZMatt ArsenaultMatthew.Arsenault@amd.com2013-05-06T02:07:24Zurn:sha1:8b9dc21d6f12a0251cdb6116c2297c13d77073d5
Use unknown results for places where it would be needed
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181176 91177308-0d34-0410-b5e6-96231b3b80d8
RegionInfo: Do not crash if unreachable block is found2013-05-03T15:48:34ZTobias Grossergrosser@fim.uni-passau.de2013-05-03T15:48:34Zurn:sha1:333403abbda5722724025cda1f8f52ef36d31505
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181025 91177308-0d34-0410-b5e6-96231b3b80d8
This patch breaks up Wrap.h so that it does not have to include all of 2013-05-01T20:59:00ZFilip Pizlofpizlo@apple.com2013-05-01T20:59:00Zurn:sha1:40be1e85665d10f5444186f0e7106e368dd735b8
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.
Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.
This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180881 91177308-0d34-0410-b5e6-96231b3b80d8
Struct-path aware TBAA: change the format of TBAAStructType node.2013-04-27T00:26:11ZManman Renmren@apple.com2013-04-27T00:26:11Zurn:sha1:a5b314c27a585b979ac9c9da944aa3cec27d22a6
We switch the order of offset and field type to make TBAAStructType node
(name, parent node, offset) similar to scalar TBAA node (name, parent node).
TypeIsImmutable is added to TBAAStructTag node.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180654 91177308-0d34-0410-b5e6-96231b3b80d8
Struct-path aware TBAA: update getMostGenericTBAA 2013-04-22T23:00:44ZManman Renmren@apple.com2013-04-22T23:00:44Zurn:sha1:2ff97832e593926ea8dbdd5fc5bcf367475638a9
The tag is of type TBAANode when flag EnableStructPathTBAA is off.
Move implementation of MDNode::getMostGenericTBAA to TypeBasedAliasAnalysis.cpp
since it depends on how to interprete the MDNodes for scalar TBAA and
struct-path aware TBAA.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180068 91177308-0d34-0410-b5e6-96231b3b80d8
Move C++ code out of the C headers and into either C++ headers2013-04-22T22:47:22ZEric Christopherechristo@gmail.com2013-04-22T22:47:22Zurn:sha1:3e39731e88f2d4f597cebc74388fd6650ca4f604
or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180063 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantFolding: ComputeMaskedBits wants the scalar size for vectors.2013-04-19T16:56:24ZBenjamin Kramerbenny.kra@googlemail.com2013-04-19T16:56:24Zurn:sha1:eb733d2a1b8683f5cb3558160cb03a442f46e46e
Fixes PR15791.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179859 91177308-0d34-0410-b5e6-96231b3b80d8
A limit of 500 was still a bit too high for some tests.2013-04-17T20:02:32ZBill Wendlingisanbard@gmail.com2013-04-17T20:02:32Zurn:sha1:d58b50b99b04bcb8199c2b0273618b6a37d61015
PR15000 has a testcase where the time to compile was bordering on 30s. When I
dropped the limit value to 100, it became a much more managable 6s. The compile
time seems to increase in a roughly linear fashion based on increasing the limit
value. (See the runtimes below.)
So, let's lower the limit to 100 so that they can get a more reasonable compile
time.
Limit Value Time
----------- ----
10 0.9744s
20 1.8035s
30 2.3618s
40 2.9814s
50 3.6988s
60 4.5486s
70 4.9314s
80 5.8012s
90 6.4246s
100 7.0852s
110 7.6634s
120 8.3553s
130 9.0552s
140 9.6820s
150 9.8804s
160 10.8901s
170 10.9855s
180 12.0114s
190 12.6816s
200 13.2754s
210 13.9942s
220 13.8097s
230 14.3272s
240 15.7753s
250 15.6673s
260 16.0541s
270 16.7625s
280 17.3823s
290 18.8213s
300 18.6120s
310 20.0333s
320 19.5165s
330 20.2505s
340 20.7068s
350 21.1833s
360 22.9216s
370 22.2152s
380 23.9390s
390 23.4609s
400 24.0426s
410 24.6410s
420 26.5208s
430 27.7155s
440 26.4142s
450 28.5646s
460 27.3494s
470 29.7255s
480 29.4646s
490 30.5001s
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179713 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a scalability issue with complex ConstantExprs.2013-04-13T12:53:18ZBenjamin Kramerbenny.kra@googlemail.com2013-04-13T12:53:18Zurn:sha1:8848680ce0ab416cb646d0a03aa6f4f6f25e7623
This is basically the same fix in three different places. We use a set to avoid
walking the whole tree of a big ConstantExprs multiple times.
For example: (select cmp, (add big_expr 1), (add big_expr 2))
We don't want to visit big_expr twice here, it may consist of thousands of
nodes.
The testcase exercises this by creating an insanely large ConstantExprs out of
a loop. It's questionable if the optimizer should ever create those, but this
can be triggered with real C code. Fixes PR15714.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179458 91177308-0d34-0410-b5e6-96231b3b80d8
Aliasing rules for struct-path aware TBAA.2013-04-11T23:24:18ZManman Renmren@apple.com2013-04-11T23:24:18Zurn:sha1:4df1854f263180fcd04cee3347990afe34749a89
Added PathAliases to check if two struct-path tags can alias.
Added command line option -struct-path-tbaa.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179337 91177308-0d34-0410-b5e6-96231b3b80d8