| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 163988
|
| |
|
|
| |
llvm-svn: 163987
|
| |
|
|
|
|
| |
declaration for the entity being documented.
llvm-svn: 163986
|
| |
|
|
|
|
|
|
| |
'function-like' type that can be annotated with \param.
Thanks to Eli Friedman for noticing!
llvm-svn: 163985
|
| |
|
|
|
|
| |
parameters.
llvm-svn: 163984
|
| |
|
|
| |
llvm-svn: 163983
|
| |
|
|
| |
llvm-svn: 163982
|
| |
|
|
|
|
| |
UnqualifiedId() properly noncopyable.
llvm-svn: 163981
|
| |
|
|
| |
llvm-svn: 163980
|
| |
|
|
| |
llvm-svn: 163979
|
| |
|
|
| |
llvm-svn: 163978
|
| |
|
|
| |
llvm-svn: 163974
|
| |
|
|
| |
llvm-svn: 163973
|
| |
|
|
|
|
|
| |
Kill flags are removed more and more aggressively during the register
allocation passes, it is better to get information from LiveIntervals.
llvm-svn: 163972
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 163970
|
| |
|
|
| |
llvm-svn: 163969
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This was only an issue if sse is disabled.
llvm-svn: 163967
|
| |
|
|
| |
llvm-svn: 163966
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
C11 7.17's atomic operations. GNU's __atomic_* builtins do allow const-qualified
atomics, though (!!) so don't restrict those.
llvm-svn: 163964
|
| |
|
|
|
|
|
| |
It's not clear if this is working yet on the buildbot. Reverting until we have
time to investigate.
llvm-svn: 163963
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
building on no-Python systems again.
llvm-svn: 163961
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
targets do not exist in the main tree so this was not noticed.
llvm-svn: 163959
|
| |
|
|
|
|
| |
an environment variable for debugging purposes.
llvm-svn: 163958
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the dynamic and static runtime class tables to
construct our isa table. This is putting the runtime
in contact with unrealized classes, which we need
to deal with in order to get accurate information.
That's the next piece of work.
<rdar://problem/10986023>
llvm-svn: 163957
|
| |
|
|
|
|
| |
Patch by Reed Kotler.
llvm-svn: 163956
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
destination.
Updated previous implementation to fix a case not covered:
// PBI: br i1 %x, TrueDest, BB
// BI: br i1 %y, TrueDest, FalseDest
The other case was handled correctly.
// PBI: br i1 %x, BB, FalseDest
// BI: br i1 %y, TrueDest, FalseDest
Also tried to use 64-bit arithmetic instead of APInt with scale to simplify the
computation. Let me know if you have other opinions about this.
llvm-svn: 163954
|
| |
|
|
|
|
| |
Collect processor resources from the subtarget defs.
llvm-svn: 163953
|
| |
|
|
|
|
| |
Infer SchedClasses from variants defined by the target or subtarget.
llvm-svn: 163952
|
| |
|
|
|
|
| |
Collect SchedClasses and SchedRW types from the subtarget defs.
llvm-svn: 163951
|
| |
|
|
| |
llvm-svn: 163950
|
| |
|
|
| |
llvm-svn: 163949
|
| |
|
|
|
|
|
|
|
| |
- The current_pos function is supposed to return all the written bytes, not the
current position of the underlying stream.
- This caused tell() to be broken whenever the underlying stream had buffered
content.
llvm-svn: 163948
|
| |
|
|
| |
llvm-svn: 163947
|
| |
|
|
|
|
| |
NULL FrontEnd and cause LLDB to crash. This patch introduces a dummy front-end which the ValueObjectSynthetic can use lacking a real FrontEnd
llvm-svn: 163946
|
| |
|
|
| |
llvm-svn: 163945
|
| |
|
|
|
|
| |
Review by Chandler Carruth.
llvm-svn: 163944
|
| |
|
|
|
|
|
|
| |
incoming SBFrame into.
<rdar://problem/12304255>
llvm-svn: 163943
|
| |
|
|
|
|
| |
case to a conditional branch and when removing dead cases.
llvm-svn: 163942
|
| |
|
|
| |
llvm-svn: 163941
|
| |
|
|
| |
llvm-svn: 163940
|
| |
|
|
|
|
|
|
|
|
|
| |
bytes of the buffer and not the size of the string, otherwise we
may overwrite the buffer if there is a mismatch between the size
of the string and the CharByteWidth, and assertions are disabled.
The bug where this could occur was fixed in r163931.
Related to rdar://12069503
llvm-svn: 163939
|
| |
|
|
| |
llvm-svn: 163938
|
| |
|
|
| |
llvm-svn: 163937
|