Alexander Potapenko via llvm-dev
2017-Jul-11 13:02 UTC
[llvm-dev] Zero-extending function parameters on x86_64
Hi llvm-dev, Yesterday we've noticed (https://bugs.llvm.org/show_bug.cgi?id=33732) that on x86_64 a function declaration created by getOrInsertFunction() must set the zeroext attribute for each parameter that is smaller than 64 bits. Failing to do so may result in LLVM passing garbage in the upper bits of the registers instead of zeroing them out in the caller. In some cases the garbage may be passed on from the called function. I've started going through sanitizer instrumentation passes and noticed some of them also declare functions with e.g. i32 parameters lacking the zeroext attribute. There also are other LLVM passes that don't set the zeroext attribute for function parameters. I find this a little counterintuitive that every user of getOrInsertFunction() should think about whatever possible ABI conventions and opt-in into the zeroext attribute. Is it feasible to make getOrInsertFunction() take care of this automatically depending on the target? Thanks, Alex -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Reid Kleckner via llvm-dev
2017-Jul-11 16:02 UTC
[llvm-dev] Zero-extending function parameters on x86_64
I think for x86_64, everything is supposed to be extended to 32-bits, but it doesn't need to go wider. At least, that was the conclusion that I took away from the last time this came up: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150907/138250.html In that case, LLVM combined two i32 loads to one i64 load and left the second i32 in the high bits of the register passed into libjpegturbo assembly. It was decided that this was correct, and libjpegturbo needed to zext. For i8s and i16s, those have to be extended to i32, but LLVM doesn't know if they are signed or unsigned, so it doesn't guess. Leaving behind garbage is pretty useless and maybe even inefficient (partial register dependency). I'm still inclined to chalk this up to another LLVM usability issue for non-C frontends. There's still a lot of work to be done in that area, and this is just one of many usability problems. On Tue, Jul 11, 2017 at 6:02 AM, Alexander Potapenko via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi llvm-dev, > > Yesterday we've noticed (https://bugs.llvm.org/show_bug.cgi?id=33732) > that on x86_64 a function declaration created by getOrInsertFunction() > must set the zeroext attribute for each parameter that is smaller than > 64 bits. > Failing to do so may result in LLVM passing garbage in the upper bits > of the registers instead of zeroing them out in the caller. In some > cases the garbage may be passed on from the called function. > > I've started going through sanitizer instrumentation passes and > noticed some of them also declare functions with e.g. i32 parameters > lacking the zeroext attribute. There also are other LLVM passes that > don't set the zeroext attribute for function parameters. > > I find this a little counterintuitive that every user of > getOrInsertFunction() should think about whatever possible ABI > conventions and opt-in into the zeroext attribute. > Is it feasible to make getOrInsertFunction() take care of this > automatically depending on the target? > > Thanks, > Alex > > -- > Alexander Potapenko > Software Engineer > > Google Germany GmbH > Erika-Mann-Straße, 33 > 80636 München > > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://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/20170711/2f6b4924/attachment.html>