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

[Hideto Ueno via llvm-dev]

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/1b98a566/attachment.html>