This is an archive of the discontinued LLVM Phabricator instance.

Tweak the LICM code to reuse the first sub-loop instead of creating a new one
ClosedPublic

Authored by gareevroman on Jan 31 2016, 12:07 AM.

Details

Summary

LICM starts with an *empty* AST, and then merges in each sub-loop. While the add code is appropriate for sub-loop 2 and up, it's utterly unnecessary for sub-loop 1. If the AST starts off empty, we can just clone/move the contents of the subloop into the containing AST.

It passes the LLVM regression tests and helps to reduce the runtime of 'opt -basicaa -licm out.opt.ll’ from 130ms to 74ms and the runtime of 'opt -basicaa -licm out.opt2.ll’ from 117ms to 68ms.

Diff Detail

Repository
rL LLVM

Event Timeline

gareevroman retitled this revision from to Tweak the LICM code to reuse the first sub-loop instead of creating a new one.
gareevroman updated this object.
gareevroman added a reviewer: reames.
gareevroman added a subscriber: grosser.
reames edited edge metadata.Feb 1 2016, 7:11 PM

Looks functionally correct, but stylistically could use some work.

lib/Transforms/Scalar/LICM.cpp
205 ↗(On Diff #46484)

Extracting this code as a helper function would make it much cleaner.

The other option would be to turn add(AST&) into add(AST&&) - e.g. move the parameter.

You might also get away with special casing the copy into an empty AST.

The general point of each of my comments above is that the complexity in ownership in the new code is high and it would be nice to reduce that if possible.

Looks functionally correct, but stylistically could use some work.

Thank you for the comments.

Extracting this code as a helper function would make it much cleaner.

The other option would be to turn add(AST&) into add(AST&&) - e.g. move the parameter.

If I’m not mistaken, ilist doesn’t support move semantics. Should we copy contents of ilist<AliasSet> AliasSets in this case?

You might also get away with special casing the copy into an empty AST.

I have a question related to this. Could you please advise me a preferred way to copy contents of one ilist<AliasSet> AliasSets to another AliasSets?

The general point of each of my comments above is that the complexity in ownership in the new code is high and it would be nice to reduce that if possible.

OK. If in this case the simplicity in ownership is more preferable than the simplicity of AliasTracker::add, let’s modify AliasTracker::add.

gareevroman edited edge metadata.

Extract code as a helper function.

Looks functionally correct, but stylistically could use some work.

Thank you for the comments.

Extracting this code as a helper function would make it much cleaner.

The other option would be to turn add(AST&) into add(AST&&) - e.g. move the parameter.

If I’m not mistaken, ilist doesn’t support move semantics. Should we copy contents of ilist<AliasSet> AliasSets in this case?

If I’m not mistaken, swap of iplist, which is a base class of ilist, is temporary disabled, because it doesn’t use list traits callback correctly yet. Maybe we could extract this code as a helper function and git rid of it, when iplist::swap is available and it is easier to turn add(AST&) into add(AST&&). What do you think about it?

You might also get away with special casing the copy into an empty AST.

I have a question related to this. Could you please advise me a preferred way to copy contents of one ilist<AliasSet> AliasSets to another AliasSets?

I’ve tried to use ilist::assign to do this. However, I get a compile time error, because a copy constructor of the AliasSet is deleted.

The general point of each of my comments above is that the complexity in ownership in the new code is high and it would be nice to reduce that if possible.

OK. If in this case the simplicity in ownership is more preferable than the simplicity of AliasTracker::add, let’s modify AliasTracker::add.

Extracting this code as a helper function would make it much cleaner.

Philip, did you propose to extract another code as a helper function? Sorry, maybe I missed something.

Minor comments only. This looks really close to landing.

lib/Transforms/Scalar/LICM.cpp
225 ↗(On Diff #47162)

Move this bit of code into your helpful function as well. With it being outside the function, the naming is misleading.

Alternatively, rename the function to something like collectAliasInfoForSubLoops.

Rename the function.

Minor comments only. This looks really close to landing.

Thank you for the comments.

reames accepted this revision.Feb 12 2016, 9:37 AM
reames edited edge metadata.

LGTM w/minor comment fix.

lib/Transforms/Scalar/LICM.cpp
1058 ↗(On Diff #47773)

minor: a better comment would be: Returns an owning pointer to an alias set which incorporates aliasing info from all subloops of L, but does not include instructions in L itself.

This revision is now accepted and ready to land.Feb 12 2016, 9:37 AM
This revision was automatically updated to reflect the committed changes.

LGTM w/minor comment fix.

Thank you for the review!