Hello,
I am facing an issue with a small test where there is a chance that
sign-extension is not introduced as expected -
#include <stdio.h>
void func( long x )
{
printf(" %ld \n", x);
}
int main()
{
char c = -1;
func ( c ); // c is zero extended to x
return 0;
}
generated IR -
define i32 @main() #0 {
........
store i8 -1, i8* %c, align 1
%2 = load i8, i8* %c, align 1
* %3 = zext i8 %2 to i64*
call void @func(i64 %3)
}
The value to the formal argument is zero-extended, different from x86_64.
Is this a known issue ? Am I missing anything ?
Thanks,
Somenath
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160907/a0bd78ac/attachment.html>
> On Sep 7, 2016, at 10:32 AM, Somenath Chakraborty via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > I am facing an issue with a small test where there is a chance that sign-extension is not introduced as expected - > > #include <stdio.h> > > void func( long x ) > { > printf(" %ld \n", x); > } > > int main() > { > char c = -1;I believe the signedness of char is implementation defined, have you tried using `signed char`? — Mehdi> func ( c ); // c is zero extended to x > return 0; > } > > generated IR - > > define i32 @main() #0 { > ........ > store i8 -1, i8* %c, align 1 > %2 = load i8, i8* %c, align 1 > %3 = zext i8 %2 to i64 > call void @func(i64 %3) > } > > The value to the formal argument is zero-extended, different from x86_64. Is this a known issue ? Am I missing anything ? > > Thanks, > Somenath > > _______________________________________________ > 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/20160907/d82750c9/attachment.html>
You are right! Now the generated code is - %3 = sext i8 %2 to i64 On Wed, Sep 7, 2016 at 11:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:> > On Sep 7, 2016, at 10:32 AM, Somenath Chakraborty via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hello, > > I am facing an issue with a small test where there is a chance that > sign-extension is not introduced as expected - > > #include <stdio.h> > > void func( long x ) > { > printf(" %ld \n", x); > } > > int main() > { > char c = -1; > > > I believe the signedness of char is implementation defined, have you tried > using `signed char`? > > — > Mehdi > > > func ( c ); // c is zero extended to x > return 0; > } > > generated IR - > > define i32 @main() #0 { > ........ > store i8 -1, i8* %c, align 1 > %2 = load i8, i8* %c, align 1 > * %3 = zext i8 %2 to i64* > call void @func(i64 %3) > } > > The value to the formal argument is zero-extended, different from x86_64. > Is this a known issue ? Am I missing anything ? > > Thanks, > Somenath > > _______________________________________________ > 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/20160907/a34f582c/attachment.html>
On 7 September 2016 at 18:32, Somenath Chakraborty via llvm-dev <llvm-dev at lists.llvm.org> wrote:> The value to the formal argument is zero-extended, different from x86_64. Is > this a known issue ? Am I missing anything ?This is specified in the ABI document: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf. Section 7.1 gives mappings from C types to underlying ones and says that "char" is actually an "unsigned byte". This applies to 32-bit AAPCS targets as well; but beware that Darwin targets don't follow AAPCS here, and char is signed again. Tim.
Was there any specific reason to take the opposite path (from x86) ? - Just curious to know. On Thu, Sep 8, 2016 at 2:33 PM, Tim Northover <t.p.northover at gmail.com> wrote:> On 7 September 2016 at 18:32, Somenath Chakraborty via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > The value to the formal argument is zero-extended, different from > x86_64. Is > > this a known issue ? Am I missing anything ? > > This is specified in the ABI document: > http://infocenter.arm.com/help/topic/com.arm.doc. > ihi0055b/IHI0055B_aapcs64.pdf. > > Section 7.1 gives mappings from C types to underlying ones and says > that "char" is actually an "unsigned byte". This applies to 32-bit > AAPCS targets as well; but beware that Darwin targets don't follow > AAPCS here, and char is signed again. > > Tim. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160908/1cd2fb71/attachment.html>