[llvm-dev] Zero-extending function parameters on x86_64

[Reid Kleckner via llvm-dev]

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>