llvm dev - Dec 2021 - Inline assembly and poison values

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

On 12/12/21 14:51, Leo Gaspard via llvm-dev wrote:
> 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?)
"like the below"? I'm confused. Adding an IR extensions requires
a RFC on the mailing list, look for recent ones to see what format
they can have. Motivation, semantics, etc. Then (or together) a
patch for the LangRef and the IR reader/writer etc. Then preferably
some users in the code base so it's not just pretty but useful ;)

Does that answer the question?

~ Johannes

>
>>> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev