llvm dev - Dec 2021 - Inline assembly and poison values

Johannes Doerfert <johannesdoerfert at gmail.com>
writes:
> I very much hope inline asm can (in general) act like a freeze
> but does not have to. That is, if we ever look into the box we
> can determine if it does freeze or not, and consequently use the
> information for follow argumentation. However, unless we look
> into the box we cannot assume anything. Hence, asm does not
> propagate poison but also does not freeze the inputs. That means
> we shall not propagate poison trough (uninterpreted) asm but also
> not remove a subsequent freeze under the assumption the asm would
> have implicitly frozen the poison already.
Do I understand correctly if I say that this means that for defining
proper semantics of the assembly+IR group, this would require defining,
for each assembly backend, what “poison” translates to and from for it?

Or maybe documentation could just say “what exactly ‘poison’ means is
backend-specific, and the outputs of an assembly block handling poisoned
data can be, or not, poisoned depending on each backend” or something
similar, thus postponing the specification work for later?

Though it'd probably be better if it were possible to have a full spec
of what exactly poison means for each backend, I guess it can take a
while to check exactly how each poison can arise and what they should
translate to for each backend in order to enable as many optimizations
as possible

On 12/7/21 14:34, Leo Gaspard wrote:
> Johannes Doerfert <johannesdoerfert at gmail.com> writes:
>> I very much hope inline asm can (in general) act like a freeze
>> but does not have to. That is, if we ever look into the box we
>> can determine if it does freeze or not, and consequently use the
>> information for follow argumentation. However, unless we look
>> into the box we cannot assume anything. Hence, asm does not
>> propagate poison but also does not freeze the inputs. That means
>> we shall not propagate poison trough (uninterpreted) asm but also
>> not remove a subsequent freeze under the assumption the asm would
>> have implicitly frozen the poison already.
> Do I understand correctly if I say that this means that for defining
> proper semantics of the assembly+IR group, this would require defining,
> for each assembly backend, what “poison” translates to and from for it?
>
> Or maybe documentation could just say “what exactly ‘poison’ means is
> backend-specific, and the outputs of an assembly block handling poisoned
> data can be, or not, poisoned depending on each backend” or something
> similar, thus postponing the specification work for later?
>
> Though it'd probably be better if it were possible to have a full spec
> of what exactly poison means for each backend, I guess it can take a
> while to check exactly how each poison can arise and what they should
> translate to for each backend in order to enable as many optimizations
> as possible
I think the second solution is what you want. We also do not
define the semantics of inline ASM, so how could we say what
it means if poison goes in. Inline ASM, as it stands, should
always be allowed to produce poison, write poison into output
registers, etc. If we want ways to encode it does not, that's
a different story. That said, I'm not sure why explicit freeze
would be bad for the output, and for the input we probably
don't care as we do not "analyze" the asm anyway. No?

~ Johannes