- Sep 16, 2012
-
-
Craig Topper authored
llvm-svn: 164002
-
Craig Topper authored
llvm-svn: 164001
-
Craig Topper authored
llvm-svn: 164000
-
Craig Topper authored
llvm-svn: 163999
-
Nadav Rotem authored
llvm-svn: 163997
-
Craig Topper authored
llvm-svn: 163996
-
Nadav Rotem authored
It had patterns for zext-loading and extending. This commit adds patterns for loading a wide type, performing a bitcast, and extending. This is an odd pattern, but it is commonly used when writing code with intrinsics. rdar://11897677 llvm-svn: 163995
-
Ted Kremenek authored
llvm-svn: 163994
-
Andrew Trick authored
llvm-svn: 163993
-
Craig Topper authored
llvm-svn: 163992
-
Jakob Stoklund Olesen authored
The live range of an SSA value forms a sub-tree of the dominator tree. That means the live ranges of two values overlap if and only if the def of one value lies within the live range of the other. This can be used to simplify the interference checking a bit: Visit each def in the two registers about to be joined. Check for interference against the value that is live in the other register at the def point only. It is not necessary to scan the set of overlapping live ranges, this interference check can be done while computing the value mapping required for the final live range join. The new algorithm is prepared to handle more complicated conflict resolution - We can allow overlapping live ranges with different values as long as the differing lanes are undef or unused in the other register. The implementation in this patch doesn't do that yet, it creates code that is nearly identical to the old algorithm's, except: - The new stripCopies() function sees through multiple copies while the old RegistersDefinedFromSameValue() only can handle one. - There are a few rare cases where the new algorithm can erase an IMPLICIT_DEF instuction that RegistersDefinedFromSameValue() couldn't handle. llvm-svn: 163991
-
Jakob Stoklund Olesen authored
A value that is live in to a basic block should be returned by valueIn() in LiveRangeQuery(getMBBStartIdx(MBB)), unless it is a PHI-def which should be returned by valueDefined() instead. Current code isn't using this functionality. Future code will. llvm-svn: 163990
-
Douglas Gregor authored
headers and modules in more detail. I'd still like to expand on some of the modules-related issues further, but this is a decent start. llvm-svn: 163989
-
Craig Topper authored
llvm-svn: 163988
-
Craig Topper authored
llvm-svn: 163987
-
- Sep 15, 2012
-
-
Dmitri Gribenko authored
declaration for the entity being documented. llvm-svn: 163986
-
Dmitri Gribenko authored
'function-like' type that can be annotated with \param. Thanks to Eli Friedman for noticing! llvm-svn: 163985
-
Dmitri Gribenko authored
parameters. llvm-svn: 163984
-
Dmitri Gribenko authored
llvm-svn: 163983
-
Dmitri Gribenko authored
llvm-svn: 163982
-
Dmitri Gribenko authored
UnqualifiedId() properly noncopyable. llvm-svn: 163981
-
Craig Topper authored
llvm-svn: 163980
-
Craig Topper authored
llvm-svn: 163979
-
Craig Topper authored
llvm-svn: 163978
-
Craig Topper authored
llvm-svn: 163974
-
Craig Topper authored
llvm-svn: 163973
-
Jakob Stoklund Olesen authored
Kill flags are removed more and more aggressively during the register allocation passes, it is better to get information from LiveIntervals. llvm-svn: 163972
-
Jakob Stoklund Olesen authored
If a PHI value happens to be live out from the layout predecessor of its def block, the def slot index will be in the middle of the segment: %vreg11 = [192r,240B:0)[352r,416B:2)[416B,496r:1) 0@192r 1@480B-phi %2@352r A LiveRangeQuery for 480 should return NULL from valueIn() since the PHI value is defined at the block entry, not live in to the block. No test case, future code depends on this functionality. llvm-svn: 163971
-
Craig Topper authored
llvm-svn: 163970
-
Craig Topper authored
llvm-svn: 163969
-
Benjamin Kramer authored
What we have so far: - Some clang test failures (these were known already) - Perf results are mixed, some big regressions http://llvm.org/perf/db_default/v4/nts/3844 http://llvm.org/perf/db_default/v4/nts/3845 bullet suffers a lot. matmul is interesting: slower scalar code, faster with -vectorize. - Some dragonegg selfhost bots crash in SROA during selfhost now http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.6-self-host-checks/builds/1632 http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.5-self-host/builds/1891 llvm-svn: 163968
-
Benjamin Kramer authored
This was only an issue if sse is disabled. llvm-svn: 163967
-
Dmitri Gribenko authored
llvm-svn: 163966
-
Chandler Carruth authored
new one, and add support for running the new pass in that mode and in that slot of the pass manager. With this the new pass can completely replace the old one within the pipeline. The strategy for enabling or disabling the SSAUpdater logic is to do it by making the requirement of the domtree analysis optional. By default, it is required and we get the standard mem2reg approach. This is usually the desired strategy when run in stand-alone situations. Within the CGSCC pass manager, we disable requiring of the domtree analysis and consequentially trigger fallback to the SSAUpdater promotion. In theory this would allow the pass to re-use a domtree if one happened to be available even when run in a mode that doesn't require it. In practice, it lets us have a single pass rather than two which was simpler for me to wrap my head around. There is a hidden flag to force the use of the SSAUpdater code path for the purpose of testing. The primary testing strategy is just to run the existing tests through that path. One notable difference is that it has custom code to handle lifetime markers, and one of the tests has been enhanced to exercise that code. This has survived a bootstrap and the test suite without serious correctness issues, however my run of the test suite produced *very* alarming performance numbers. I don't entirely understand or trust them though, so more investigation is on-going. To aid my understanding of the performance impact of the new SROA now that it runs throughout the optimization pipeline, I'm enabling it by default in this commit, and will disable it again once the LNT bots have picked up one iteration with it. I want to get those bots (which are much more stable) to evaluate the impact of the change before I jump to any conclusions. NOTE: Several Clang tests will fail because they run -O3 and check the result's order of output. They'll go back to passing once I disable it again. llvm-svn: 163965
-
Richard Smith authored
C11 7.17's atomic operations. GNU's __atomic_* builtins do allow const-qualified atomics, though (!!) so don't restrict those. llvm-svn: 163964
-
Ted Kremenek authored
It's not clear if this is working yet on the buildbot. Reverting until we have time to investigate. llvm-svn: 163963
-
Jordan Rose authored
Specifically, this should warn: __block block_t a = ^{ a(); }; Furthermore, this case which previously warned now does not, since the value of 'b' is captured before the assignment occurs: block_t b; // not __block b = ^{ b(); }; (This will of course warn under -Wuninitialized, as before.) <rdar://problem/11015883> llvm-svn: 163962
-
Jason Molenda authored
building on no-Python systems again. llvm-svn: 163961
-
Akira Hatanaka authored
use load/store fragments defined in TargetSelectionDAG.td in place of them. Unaligned loads/stores are either expanded or lowered to target-specific nodes, so instruction selection should see only aligned load/store nodes. No changes in functionality. llvm-svn: 163960
-
Craig Topper authored
Revert r163878 as it breaks on targets with alternate register names. Such targets do not exist in the main tree so this was not noticed. llvm-svn: 163959
-