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

Nuno Lopes via llvm-dev llvm-dev at lists.llvm.org
Sun Oct 23 09:30:03 PDT 2016


> 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?

Nuno



More information about the llvm-dev mailing list