[llvm-dev] Inline assembly and poison values

[Leo Gaspard via llvm-dev]

Johannes Doerfert <johannesdoerfert at gmail.com> writes:
>> 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?
>
> 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?

It totally makes sense to me! Out of curiosity, what is the process for
adding a clause like the below in the reference? (eg. waiting some delay
then submitting a formal change, getting it reviewed and landing it?)

>> 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 and the exact contents of the assembly
>> block. In particular, the backend is allowed to peer into the
>> assembly block and optimize depending on that.

PS: Sorry for the duplicate mail on your personal email, I forgot to use
the correct sender address