(original) (raw)
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@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 executionbecause 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 )Regards,HidetoOn Mon, Aug 16, 2021 at 8:50 PM Hideto Ueno <uenoku.tokotoko@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 executionbecause 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 )Regards,HidetoOn Mon, Aug 16, 2021 at 6:55 PM Charitha Saumya via llvm-dev <llvm-dev@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) ?ThanksCharitha
LLVM Developers mailing list
llvm-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev