i1* function argument on x86-64

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

i1* function argument on x86-64

Frank Winter
I am running into a problem with 'i1*' as a function's argument which
seems to have appeared since I switched to LLVM 3.6 (but can have other
source, of course). If I look at the assembler that the MCJIT generates
for an x86-64 target I see that the array 'i1*' is taken as a sequence
of 1 bit wide elements. (I guess that's correct). However, I used to
call the function from C passing in a 'bool*' which has 1 byte
wideelements, I guess. (not sure if that's a compiler's choice) Now,
since I haven't changed my code on these parts but only made the
transition from LLVM 3.4/5 -> 3.6 I wonder if the element width has
changed when i1* is used as a function's argument..!?

Thanks,
Frank

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: i1* function argument on x86-64

Frank Winter
I attach the orginal IR and the generated assembly where one can see
that the array elements are treated 1 bit wide. Is this the intended
behavior? I doubt it, because I am passing in C pointers, and those have
byte granularity. (In C a bit cannot be addressed with a pointer).

Frank



On 07/27/2015 01:44 PM, Frank Winter wrote:

> I am running into a problem with 'i1*' as a function's argument which
> seems to have appeared since I switched to LLVM 3.6 (but can have
> other source, of course). If I look at the assembler that the MCJIT
> generates for an x86-64 target I see that the array 'i1*' is taken as
> a sequence of 1 bit wide elements. (I guess that's correct). However,
> I used to call the function from C passing in a 'bool*' which has 1
> byte wideelements, I guess. (not sure if that's a compiler's choice)
> Now, since I haven't changed my code on these parts but only made the
> transition from LLVM 3.4/5 -> 3.6 I wonder if the element width has
> changed when i1* is used as a function's argument..!?
>
> Thanks,
> Frank
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

copymask.ll (4K) Download Attachment
copymask.S (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: i1* function argument on x86-64

Jonathan Roelofs
In reply to this post by Frank Winter


On 7/27/15 11:44 AM, Frank Winter wrote:
> I am running into a problem with 'i1*' as a function's argument which
> seems to have appeared since I switched to LLVM 3.6 (but can have other
> source, of course). If I look at the assembler that the MCJIT generates
> for an x86-64 target I see that the array 'i1*' is taken as a sequence
> of 1 bit wide elements. (I guess that's correct).

Yes, that is correct.

> However, I used to
> call the function from C passing in a 'bool*' which has 1 byte
> wideelements, I guess.

This is the bug, as the caller and callee need to agree on how data for
arguments is laid out. 'bool' is i8 in clang when stored to memory (for
most targets... IIRC, one of the ppc darwin targets has 32bit bools?).

> (not sure if that's a compiler's choice) Now,

Width of 'bool' is a frontend choice, yes. In C, the minimum addressable
thing has to have the same size as char, and the assumption that char is
8 bits is very baked into llvm.

> since I haven't changed my code on these parts but only made the
> transition from LLVM 3.4/5 -> 3.6 I wonder if the element width has
> changed when i1* is used as a function's argument..!?

I'm not sure of the history here. Perhaps it could have been a bugfix?


Cheers,

Jon

>
> Thanks,
> Frank
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

--
Jon Roelofs
[hidden email]
CodeSourcery / Mentor Embedded
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: i1* function argument on x86-64

Frank Winter
Okay, it might got fixed along the way.
Then, the only portable way of doing this is to change the function
argument from 'i1*' to 'i<X>*' (plus the code changing it to an i1) and
add a new parameter <X> to my code which specifies the bit width of a
bool that the C compiler uses.

Frank

On 07/27/2015 02:01 PM, Jonathan Roelofs wrote:

>
>
> On 7/27/15 11:44 AM, Frank Winter wrote:
>> I am running into a problem with 'i1*' as a function's argument which
>> seems to have appeared since I switched to LLVM 3.6 (but can have other
>> source, of course). If I look at the assembler that the MCJIT generates
>> for an x86-64 target I see that the array 'i1*' is taken as a sequence
>> of 1 bit wide elements. (I guess that's correct).
>
> Yes, that is correct.
>
>> However, I used to
>> call the function from C passing in a 'bool*' which has 1 byte
>> wideelements, I guess.
>
> This is the bug, as the caller and callee need to agree on how data
> for arguments is laid out. 'bool' is i8 in clang when stored to memory
> (for most targets... IIRC, one of the ppc darwin targets has 32bit
> bools?).
>
>> (not sure if that's a compiler's choice) Now,
>
> Width of 'bool' is a frontend choice, yes. In C, the minimum
> addressable thing has to have the same size as char, and the
> assumption that char is 8 bits is very baked into llvm.
>
>> since I haven't changed my code on these parts but only made the
>> transition from LLVM 3.4/5 -> 3.6 I wonder if the element width has
>> changed when i1* is used as a function's argument..!?
>
> I'm not sure of the history here. Perhaps it could have been a bugfix?
>
>
> Cheers,
>
> Jon
>
>>
>> Thanks,
>> Frank
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev