Mikael Egevig via llvm-dev
2019-Jul-08 02:54 UTC
[llvm-dev] Problem with the LLVM v8.0 IR 'select' instruction
Hi again, It is probably me doing something wrong, but I have attached a trimmed down sample that shows the issue and the output that Clang 8.0.0 makes (using the binary release from llvm.org). I invoke clang as follows: clang -S -O3 -o Evergrowing.s -Wall Evergrowing.ll I tried using -O1, -O2, and -O3, but all where the same. Please notice that I renamed 'main()' to 'mainfunc()' to be sure Clang isn't picking up 'main()' as a reserved, special function. This on a Windows 10 x64 PC, but I got exactly the same behavior on arm7hf and aarch64. Cheers, Mikael Egevig Den man. 8. jul. 2019 kl. 04.30 skrev Mehdi AMINI <joker.eph at gmail.com>:> Hi, > > > > On Sun, Jul 7, 2019 at 4:26 PM Mikael Egevig via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi guys, >> >> I am doing a hobby compiler using LLVM. I have a rather peculiar problem >> with the 'select' instruction, as far as I can see. Given this code: >> >> ************************************************ >> ; Run-time Library Definitions >> %Exception = type { i8 } >> >> define private %Exception* @Start(i1* %$result) #0 >> { >> prologue: >> store i1 true, i1* %$result >> br label %epilogue >> epilogue: >> ret %Exception* null >> } >> >> ; Generated main() function. >> define i32 @main(i32 %argc, i8** %argv) >> { >> prologue: >> %0 = alloca i1 >> %1 = call %Exception *@Start(i1* %0) >> %2 = load i1, i1* %0 >> %3 = select i1 %2, i32 0, i32 1 >> ret i32 %3 >> } >> ************************************************ >> >> I'd expect the 'select' instruction in main() to yield zero, not one. >> > > Seems correct to me. > > >> But when I compile the sample on x86_64, arm7, and aarch64, I always >> get code that yields one. >> > > Can you provide a reproducer? > As far as I can tell the optimizer folds the code you provided above to > yield 0: https://godbolt.org/z/T5wkSJ > > -- > Mehdi > > > >> >> The idea is that if the program, @Start, returns false, one should be >> returned to the OS and vice versa. I guess I could use 'not' instead of >> 'select', but I don't understand the behavior of 'select'. >> >> The above code is automatically generated, except I have removed all >> irrelevant code generated by the compiler. >> >> I'm not sure if LLVM gets confused by me returning the result in an >> alloca'ed area, but I use the return value, of all functions, for the >> exception pointer (null = no exception). >> >> Thanks in advance! >> >> >> Cheers, >> Mikael Egevig >> >> _______________________________________________ >> 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/20190708/b5e697b8/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Evergrowing.ll Type: application/octet-stream Size: 1385 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190708/b5e697b8/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: Evergrowing.s Type: application/octet-stream Size: 427 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190708/b5e697b8/attachment-0001.obj>
Craig Topper via llvm-dev
2019-Jul-08 03:53 UTC
[llvm-dev] Problem with the LLVM v8.0 IR 'select' instruction
I believe your issue is that @Start has the readnone attribute. This is telling the optimizers that @Start doesn't read or write any memory. ~Craig On Sun, Jul 7, 2019 at 7:54 PM Mikael Egevig via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi again, > > It is probably me doing something wrong, but I have attached a trimmed > down sample that shows the issue and the output that Clang 8.0.0 makes > (using the binary release from llvm.org). > > I invoke clang as follows: clang -S -O3 -o Evergrowing.s -Wall > Evergrowing.ll > > I tried using -O1, -O2, and -O3, but all where the same. Please notice > that I renamed 'main()' to 'mainfunc()' to be sure Clang isn't picking up > 'main()' as a reserved, special function. > > This on a Windows 10 x64 PC, but I got exactly the same behavior on arm7hf > and aarch64. > > > Cheers, > Mikael Egevig > > > Den man. 8. jul. 2019 kl. 04.30 skrev Mehdi AMINI <joker.eph at gmail.com>: > >> Hi, >> >> >> >> On Sun, Jul 7, 2019 at 4:26 PM Mikael Egevig via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi guys, >>> >>> I am doing a hobby compiler using LLVM. I have a rather peculiar >>> problem with the 'select' instruction, as far as I can see. Given this >>> code: >>> >>> ************************************************ >>> ; Run-time Library Definitions >>> %Exception = type { i8 } >>> >>> define private %Exception* @Start(i1* %$result) #0 >>> { >>> prologue: >>> store i1 true, i1* %$result >>> br label %epilogue >>> epilogue: >>> ret %Exception* null >>> } >>> >>> ; Generated main() function. >>> define i32 @main(i32 %argc, i8** %argv) >>> { >>> prologue: >>> %0 = alloca i1 >>> %1 = call %Exception *@Start(i1* %0) >>> %2 = load i1, i1* %0 >>> %3 = select i1 %2, i32 0, i32 1 >>> ret i32 %3 >>> } >>> ************************************************ >>> >>> I'd expect the 'select' instruction in main() to yield zero, not one. >>> >> >> Seems correct to me. >> >> >>> But when I compile the sample on x86_64, arm7, and aarch64, I always >>> get code that yields one. >>> >> >> Can you provide a reproducer? >> As far as I can tell the optimizer folds the code you provided above to >> yield 0: https://godbolt.org/z/T5wkSJ >> >> -- >> Mehdi >> >> >> >>> >>> The idea is that if the program, @Start, returns false, one should be >>> returned to the OS and vice versa. I guess I could use 'not' instead of >>> 'select', but I don't understand the behavior of 'select'. >>> >>> The above code is automatically generated, except I have removed all >>> irrelevant code generated by the compiler. >>> >>> I'm not sure if LLVM gets confused by me returning the result in an >>> alloca'ed area, but I use the return value, of all functions, for the >>> exception pointer (null = no exception). >>> >>> Thanks in advance! >>> >>> >>> Cheers, >>> Mikael Egevig >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ > 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/20190707/7bb90af4/attachment-0001.html>
Mikael Egevig via llvm-dev
2019-Jul-08 03:55 UTC
[llvm-dev] Problem with the LLVM v8.0 IR 'select' instruction
Ouch! Thanks for your help :-) Cheers, Mikael Egevig Den man. 8. jul. 2019 kl. 05.53 skrev Craig Topper <craig.topper at gmail.com>:> I believe your issue is that @Start has the readnone attribute. This is > telling the optimizers that @Start doesn't read or write any memory. > > ~Craig > > > On Sun, Jul 7, 2019 at 7:54 PM Mikael Egevig via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi again, >> >> It is probably me doing something wrong, but I have attached a trimmed >> down sample that shows the issue and the output that Clang 8.0.0 makes >> (using the binary release from llvm.org). >> >> I invoke clang as follows: clang -S -O3 -o Evergrowing.s -Wall >> Evergrowing.ll >> >> I tried using -O1, -O2, and -O3, but all where the same. Please notice >> that I renamed 'main()' to 'mainfunc()' to be sure Clang isn't picking up >> 'main()' as a reserved, special function. >> >> This on a Windows 10 x64 PC, but I got exactly the same behavior on >> arm7hf and aarch64. >> >> >> Cheers, >> Mikael Egevig >> >> >> Den man. 8. jul. 2019 kl. 04.30 skrev Mehdi AMINI <joker.eph at gmail.com>: >> >>> Hi, >>> >>> >>> >>> On Sun, Jul 7, 2019 at 4:26 PM Mikael Egevig via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Hi guys, >>>> >>>> I am doing a hobby compiler using LLVM. I have a rather peculiar >>>> problem with the 'select' instruction, as far as I can see. Given this >>>> code: >>>> >>>> ************************************************ >>>> ; Run-time Library Definitions >>>> %Exception = type { i8 } >>>> >>>> define private %Exception* @Start(i1* %$result) #0 >>>> { >>>> prologue: >>>> store i1 true, i1* %$result >>>> br label %epilogue >>>> epilogue: >>>> ret %Exception* null >>>> } >>>> >>>> ; Generated main() function. >>>> define i32 @main(i32 %argc, i8** %argv) >>>> { >>>> prologue: >>>> %0 = alloca i1 >>>> %1 = call %Exception *@Start(i1* %0) >>>> %2 = load i1, i1* %0 >>>> %3 = select i1 %2, i32 0, i32 1 >>>> ret i32 %3 >>>> } >>>> ************************************************ >>>> >>>> I'd expect the 'select' instruction in main() to yield zero, not one. >>>> >>> >>> Seems correct to me. >>> >>> >>>> But when I compile the sample on x86_64, arm7, and aarch64, I always >>>> get code that yields one. >>>> >>> >>> Can you provide a reproducer? >>> As far as I can tell the optimizer folds the code you provided above to >>> yield 0: https://godbolt.org/z/T5wkSJ >>> >>> -- >>> Mehdi >>> >>> >>> >>>> >>>> The idea is that if the program, @Start, returns false, one should be >>>> returned to the OS and vice versa. I guess I could use 'not' instead of >>>> 'select', but I don't understand the behavior of 'select'. >>>> >>>> The above code is automatically generated, except I have removed all >>>> irrelevant code generated by the compiler. >>>> >>>> I'm not sure if LLVM gets confused by me returning the result in an >>>> alloca'ed area, but I use the return value, of all functions, for the >>>> exception pointer (null = no exception). >>>> >>>> Thanks in advance! >>>> >>>> >>>> Cheers, >>>> Mikael Egevig >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> _______________________________________________ >> 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/20190708/f418d265/attachment.html>