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

[Alexandre Isoard via llvm-dev]

On Tue, Nov 8, 2016 at 12:48 PM, Friedman, Eli via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> It's possible we could tweak your model a little to make poison a bit-wise
> property, so an i32 can be partially poison, sort of like how undef
> currently works.  Then we can consider on an operation by operation basis
> how it propagates poison bits.  In other words, let's pretend every Value
> has type <n x i1> for the purpose of poison until we actually do math on it.
>
> Under this model, we can say a non-vector icmp with any poisoned bit as
> input returns poison, but a load produces a value whose bits are poison
> only where the input is poison.  We can say "freeze(load i32)" does the
> same thing as "bitcast(freeze(load <32 x i1>) to i32)".  We can define lshr
> and trunc to allow merging two i8 loads into an i16 load.  Not sure what
> the rules for arithmetic and logic operations would be off the top of my
> head; there are some tradeoffs here.
>
This seems ok for bit-wise operations but what about more complex ones like
multiplication?
We probably want to keep the fact that multiplying by a power of two is
equivalent to a shift, no?

Anyway, I didn't follow the discussion. I understand that we want an undef
with a proper semantic (it can be substituted by any value but only at it's
definition and not at every use).
But I don't understand what is the semantic of poison, isn't poison a value
that we can assume never arise? That is, if there are necessary constraints
on the input of a function for poison to not happen,
then we can safely assume those constraints.

I don't understand why we want to mixup the semantic of poison and undef.
But then, I am lost anyway, you can safely disregard my comments on the
subject. :-)

I'm not sure this is the right approach (this model is more complicated,
> and we probably lose a bit of optimization power in some cases), but it's
> definitely nicer from the perspective of SROA and GVN.
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161108/59879315/attachment.html>