Hideto Ueno via llvm-dev
2021-Aug-16 11:55 UTC
[llvm-dev] Semantics of udef values in PHI instructions
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>
Charitha Saumya via llvm-dev
2021-Aug-16 14:00 UTC
[llvm-dev] Semantics of udef values in PHI instructions
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>