diff options
author | Chandler Carruth <chandlerc@gmail.com> | 2012-03-16 06:10:13 +0000 |
---|---|---|
committer | Chandler Carruth <chandlerc@gmail.com> | 2012-03-16 06:10:13 +0000 |
commit | f91f5af802bd4487c49ee17cd0d3e46c6456263e (patch) | |
tree | ad044f54abd72ef3a09627ca697c064561280cd0 /test/Transforms/Inline/noinline.ll | |
parent | eb5cd610700661bc46c660640c36949033247d2d (diff) | |
download | external_llvm-f91f5af802bd4487c49ee17cd0d3e46c6456263e.zip external_llvm-f91f5af802bd4487c49ee17cd0d3e46c6456263e.tar.gz external_llvm-f91f5af802bd4487c49ee17cd0d3e46c6456263e.tar.bz2 |
Start removing the use of an ad-hoc 'never inline' set and instead
directly query the function information which this set was representing.
This simplifies the interface of the inline cost analysis, and makes the
always-inline pass significantly more efficient.
Previously, always-inline would first make a single set of every
function in the module *except* those marked with the always-inline
attribute. It would then query this set at every call site to see if the
function was a member of the set, and if so, refuse to inline it. This
is quite wasteful. Instead, simply check the function attribute directly
when looking at the callsite.
The normal inliner also had similar redundancy. It added every function
in the module with the noinline attribute to its set to ignore, even
though inside the cost analysis function we *already tested* the
noinline attribute and produced the same result.
The only tricky part of removing this is that we have to be able to
correctly remove only the functions inlined by the always-inline pass
when finalizing, which requires a bit of a hack. Still, much less of
a hack than the set of all non-always-inline functions was. While I was
touching this function, I switched a heavy-weight set to a vector with
sort+unique. The algorithm already had a two-phase insert and removal
pattern, we were just needlessly paying the uniquing cost on every
insert.
This probably speeds up some compiles by a small amount (-O0 compiles
with lots of always-inline, so potentially heavy libc++ users), but I've
not tried to measure it.
I believe there is no functional change here, but yell if you spot one.
None are intended.
Finally, the direction this is going in is to greatly simplify the
inline cost query interface so that we can replace its implementation
with a much more clever one. Along the way, all the APIs get simplified,
so it seems incrementally good.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152903 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/Transforms/Inline/noinline.ll')
0 files changed, 0 insertions, 0 deletions