[PATCH] PRE: hoist operations into common dominator when possible.

[Daniel Berlin]

LGTM then.



On Thu, Aug 21, 2014 at 4:15 AM, Erik Verbruggen <erikjv at me.com> wrote:

>
> On 15 Aug 2014, at 22:28, Daniel Berlin <dberlin at dberlin.org> wrote:
>
> This looks fine to me, though note that PRE would not normally do this
> because it's not "lifetime optimal" (since it extends the lifetime of the
> multiply), which is PRE's goal.  Doing what you are doing can at least
> theoretically be a lose for performance in some cases due to increasing
> register pressure.
>
>
> I'm aware of that. I ran the llvm test-suite, and didn't notice any
> regressions. If the lnt bots do find one, I don't mind having it reverted
> (provided that it actually goes in).
>
> I'm curious if this was driven just by that comment, or if it helps some
> case you are thinking about.
>
>
> This was more of a "drive-by fix", after looking at GVN for overflow
> intrinsics. That latter one does improve a couple of cases I have, but not
> this one. (So it would be great if you could review that patch too.)
>
> -- Erik.
>
> If the latter, you also can't go much farther than this though without
> ending up writing a general code motion implementation (like
> https://courses.cs.washington.edu/courses/cse501/06wi/reading/click-pldi95.pdf),
> which i'm not aware of really being used very much in practice.
>
> As an aside, GCC eventually implemented hoisting a problem that shares
> GVNPRE's dataflow for the most part (see
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=26665)
>
>
>
> On Fri, Aug 15, 2014 at 3:36 AM, Erik Verbruggen <erikjv at me.com> wrote:
>
>> When PRE detects a common operation after a basic diamond case and in
>> one predecessor in that diamond, then hoist that operation in the common
>> dominator of the predecessors instead of moving the operation into the
>> predecessor lacking it.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140821/d1b226c6/attachment.html>