[llvm-commits] Dead argument elimination rewrite

Matthijs Kooijman matthijs at stdin.nl
Tue Jun 17 01:44:00 PDT 2008


Hi Dan,

> I don't think it's a high priority, but a "flatten return values" pass
> would be nice to have.
I have one lying around that is general enough IIRC, I'll only have to pull it
out of our local namespace into llvm :-)

> I'm going to be working on having LLVM auto-upgrade old-style multiple
> return values to struct returns next. That change will eliminate any
> regressions due to not handling them :-).
Ah, that sounds like a sound idea :-)

> UseMap is a std::multimap that maps every argument and return value
> to every argument or return value that it "uses". That caught my
> eye as a potential scalability suspect. Have you done any testing
> on large inputs?
I've done some testing on the basictest.ll testcase, copied about a hundred
times (in the same file). Execution times are very similar to the old version
(around 43ms according to -time-passes). I've also did the same thing to a new
testcase that has a lot of unused return values (parts of struct returns).
Here, the new code needs over twice as much time, but that's mainly due to it
removing stuff that the old code didn't.

I also tried using a hash_multimap instead of a normal multimap, but that
didn't seem to make much of a difference. Perhaps on even larger inputs, but
I'll leave it at multimap for now since the hash version is non-standard.

> The InspectedFunctions member variable looks redundant. Can it be
> removed?
I added it, to prevent infinite looping. When removing stuff from a function,
a new function is created with the new function type. This variable helps to
prevent the new function from being stripped as well.

Alternatively, I could make a copy of the function list and iterate over that,
which should have the same effect.

> In MarkLive:
> 
>    UseMap::iterator Begin = Uses.lower_bound(RA);
>    UseMap::iterator E = Uses.end();
>    UseMap::iterator I;
>    for (I = Begin; I != E && I->first == RA; ++I)
>      MarkLive(I->second);
> 
> This would be a little simpler using Uses.upper_bound(RA).
Yeah, but I reckoned that would require more traversing of the tree and hence
be slower. I've now rewritten it to use equal_range instead, which is probably
the best tradeoff between performance and simplicity (also, hash_multimap
required this).

> There are several instances of code like this:
> 
>        return Result;
>      } else {
> 
> Because of the return, it's not necessary to put the following code
> in a block under an else. Simplifying these, especially in SurveyUse,
> can make the code less nested and easier to read.
Done.

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20080617/de92238e/attachment.sig>


More information about the llvm-commits mailing list