[llvm-dev] [RFC] Making GVN able to visit the same block more than once

[Daniel Berlin via llvm-dev]

>
>
> =========
>
> Some questions I have:
>  * Is GVN actually the right place to do this transformation, or is there
> some
>    other better place that I've missed?
>

Truthfully, at this point, GVN is probably not the right place for almost
anything you want to do.

As you've discovered, it's a mess at this point.

The downside is the transform requires building some stuff from scratch
elsewhere (NewGVN, etc).  People often just want to get stuff done, so they
don't.
(i understand the mentality, for sure, i'm just stating the state of the
world)

On plus side, a bunch of people have posted mostly-correct, working, full
pre implementations that are hooked into NewGVN.

Note also that one thing you are likely hitting is that memdep's caching
behavior is *badly* broken.
IIRC (it's been a few weeks), it doesn't handle he case a non-local dep
becomes local (or maybe it was vice versa) properly at all.

See the pr's referenced by https://reviews.llvm.org/D45238

The " * The 'if' becomes a select and GVN and MemoryDependenceAnalysis
can't cope
   with selects. This isn't too hard I think, and I have a prototype for
this
   which essentially treats them as kind of like a phi and that mostly
works."

problem is well known now, and imho, this is yet another reason we should
stop canonicalizing to select this early.
There is a PR or two open about this, and work has been done to make it so
we can.

Trying to treat it like a phi, as you said, somewhat works, but there are
cases it will not (detailed in the prs), and you really do have to have
real control flow to compute the dataflow problem sanely (real only in the
sense of seeing it as control flow. However, you would have to have fake
instructions and fake blocks).  In particular, the "treat as phi" situation
fails very quickly when you have to insert instructions in the blocks, have
select over select etc.

So sorry, i don't have great answers for you here.

But i don't think trying to hack this through gvn and memdep, vs work on
better architecture, is the right solution.

But i've also felt that for a long time, and spent quite a while on
replacements :)
So you may also want a second opinion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180418/4c7d9f3f/attachment.html>