[LLVMdev] 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
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>