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

[Erik Verbruggen]

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/6c30d59a/attachment.html>