[llvm-dev] Semantics of udef values in PHI instructions

[Charitha Saumya via llvm-dev]

Thanks for the nice explanation.

Can I depend on this behaviour? In the example, this %unify.phi is added by
one of my custom passes. Can I assume that if a loop is present the real
value of %c.2 will still be %c.1 regardless of loop's execution behavior.

Thanks
Charitha


On Mon, Aug 16, 2021 at 7:55 AM Hideto Ueno <uenoku.tokotoko at gmail.com>
wrote:

> Hi,
>
> I don't know how lli picks the value for `undef` but I think optimizations
> eliminate the `undef` value in phi before the execution
> because optimization is allowed to change `undef` to an arbitrary
> value[0], so `undef` can be replaced by %c.1.
> For example, early-cse optimizes `%c.2` to `%c.2 = phi i32 [ %c.0,
> %while.end ], [ %c.1, %while.end12 ]`.
> (link: https://godbolt.org/z/e1M7x5z5K )
>
> [0] https://llvm.org/docs/LangRef.html#undefined-values
>
> Regards,
> Hideto
>
> On Mon, Aug 16, 2021 at 8:50 PM Hideto Ueno <uenoku.tokotoko at gmail.com>
> wrote:
>
>> Hi,
>>
>> I don't know how lli picks the value for `undef` but I think
>> optimizations eliminate the `undef` value in phi before the execution
>> because optimization is allowed to change `undef` to an arbitrary
>> value[0], so `undef` can be replaced by %c.1.
>> For example, early-cse optimizes `%c.2` to `%c.2 = phi i32 [ %c.0,
>> %while.end ], [ %c.1, %while.end12 ]`.
>> (link: https://godbolt.org/z/e1M7x5z5K )
>>
>> [0] https://llvm.org/docs/LangRef.html#undefined-values
>>
>> Regards,
>> Hideto
>>
>> On Mon, Aug 16, 2021 at 6:55 PM Charitha Saumya via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> Consider the following LLVM IR snippet. (also attached)
>>>
>>> the value of %unify.phi is undefined if the loop body (while.body9)  is
>>> executed, otherwise it has some specific value (%c.1 is a defined value).
>>>
>>> However when I execute this IR (using lli), the value of %c.2 is always
>>> the value of %c.1, even if the loop is executed multiple times.
>>>
>>> What is the reason for this behavior?  how undefined values are handled
>>> in LLVM and is this behaviour architecture dependent (depending on how
>>> undef is handled in Codegen) ?
>>>
>>> Thanks
>>> Charitha
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210816/5bcafaeb/attachment.html>