[llvm-dev] RFC: Killing undef and spreading poison

[Daniel Berlin via llvm-dev]

On Sun, Oct 23, 2016 at 9:30 AM, Nuno Lopes <nuno.lopes at ist.utl.pt> wrote:

> > So just to be clear (mainly so i can go back to letting y'all hash this
> out), in value numbering:
> > 1. I can value number all freeze operations on the same operand to the
> same value
> >  *as long as*
> > 2. I  replace all freeze values of the same operand with a single one.
> >
> > Or am i misunderstanding?
> > If i've got it right, the issue i see with #2 is whether i can hoist
> freezes or not.
> >
> > If not, it may not be possible to cover all uses.
> >
> > IE
> > if (a)  {
> >   %1 = freeze (%x)
> > } else if (b) {
> >   %2 = freeze (%x)
> > } else if (c){
> >   %3 = freeze (%x)
> > }
> >
> > I cannot replace these with a single freeze def without placing a freeze
> above the if block.
>
> As Sanjoy said, hoisting freeze is fine, but movement is not without
> constraints.  For example, you cannot duplicate execution of freeze.
> e.g. the following is wrong (assuming loop body may execute multiple
> times):
>
> %x = freeze %y
> while(...) { use %x }
> =>
> while(...) {
>    %x = freeze %y
>    use %x
> }
>
> So Sanjoy saying that freeze can be thought as an atomic/volatile
> operation seems like a good intuition.
>
>
> > *If* i need to replace them all with the same freeze def in order to be
> able to consider them the same value,  (...)
>
> Right, so just to make it very clear, the following would be wrong:
> %x = freeze %y
> %w = freeze %y
> use_1 %x
> use_2 %w
> use_3 %x
> =>
> %x = freeze %y
> %w = freeze %y
> use_1 %w
> use_2 %w
> use_3 %x
>
> If you replace one use of %x, all uses have to be replaced, since
> different freezes of the same operand *may* return different values.
> I guess that since we are never (err, most of the times) sure of whether a
> value may come out of freeze, this rule needs to be applied to any value.
> Daniel: is that fine for GVN, or would it make things too complicated?
>

Current GVN will definitely get this wrong and would be hard to fix because
of how it eliminates (IE it may cause performance regression)

We can make newgvn get it right.


>
> Nuno
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161024/4a59dab0/attachment.html>