[PATCH] D36287: [SimplifyCFG] Simplify based on a dominating condition (looking past hammocks and diamonds).

[Daniel Berlin via llvm-commits]

If you do discover testcases where these passes are actually *missing*
optimization, we'd love to see them.
(as you surmise, there's little we can do about the ones that come after
;P).

Otherwise, it would be pretty easy to build a predicateinfo based pass to
clean up here if it's valuable.
Predicateinfo takes < 600ms on > 1 million blocks/conditionals (where even
constructing the dominator tree takes 700-800ms), so it's unlikely to
affect compile time in any real way.




On Fri, Aug 4, 2017 at 9:41 AM, Chad Rosier via Phabricator <
reviews at reviews.llvm.org> wrote:

> mcrosier added a comment.
>
> In https://reviews.llvm.org/D36287#831132, @efriedma wrote:
>
> > We already have a couple other passes which can do optimize your
> testcase (JumpThreading and GVN); what do we gain from doing this analysis
> here specifically?
>
>
> Just to follow up on your question, Eli.  I suspect the fact that
> SimplifyCFG runs more frequently than JT and GVN result in a few additional
> cases being captured (perhaps cases exposed after JT/GVN).  However, I
> honestly haven't done the full investigation to get a definitive answer.
> Again, this is just derivative work and I'm not particularly set on getting
> this committed.
>
>
> https://reviews.llvm.org/D36287
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170804/48ba9ba6/attachment.html>