[cfe-dev] preserving type signatures

[Chris Lattner]

On Mar 24, 2010, at 7:36 AM, Naoya Maruyama wrote:

> Victor, thanks for pointing out the discussion, though unfortunately
> there is no way to work around the ABI issue.

You can probably work around this by implementing your own target, and having it lower the ABI types in a way that you would prefer.  X86-64 is one of the more brutal targets for type hacking.

-Chris

> 
> Thanks,
> Naoya
> 
> On Wed, Mar 24, 2010 at 11:09 PM, Victor Zverovich
> <victor.zverovich at googlemail.com> wrote:
>> It has been discussed on the list recently:
>> http://old.nabble.com/64bit-MRV-problem:-{-float,-float,-float}-->-{-double,-float-}-td27304830.html
>> 
>> Best regards,
>> Victor
>> On 24 March 2010 13:24, Naoya Maruyama <naoya.maruyama at gmail.com> wrote:
>>> 
>>> Renato,
>>> 
>>> Here's a sample code that is compiled as I wrote:
>>> 
>>> -------------------------------------------------
>>> struct dim2
>>> {
>>>    float x;
>>>    float y;
>>> };
>>> 
>>> struct dim2 kernel(struct dim2 *g)
>>> {
>>>    return *g;
>>> }
>>> -------------------------------------------------
>>> 
>>> When this code is compiled with the clang command in the LLVM/Clang
>>> 2.6 binary tarball:
>>> 
>>> -------------------------------------------------
>>> $ clang --version
>>> clang version 1.0
>>> (https://llvm.org/svn/llvm-project/cfe/branches/release_26 exported)
>>> Target: x86_64-unknown-linux-gnu
>>> Thread model: posix
>>> $ clang -Wall -emit-llvm -S test.c -o -
>>> ; ModuleID = 'test.c'
>>> target datalayout =
>>> 
>>> "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
>>> target triple = "x86_64-unknown-linux-gnu"
>>> 
>>> %struct.dim2 = type { float, float }
>>> 
>>> define double @kernel(%struct.dim2* %g) nounwind {
>>> entry:
>>>  %retval = alloca %struct.dim2                   ; <%struct.dim2*>
>>> [#uses=2]
>>>  %g.addr = alloca %struct.dim2*                  ; <%struct.dim2**>
>>> [#uses=2]
>>>  store %struct.dim2* %g, %struct.dim2** %g.addr
>>>  %tmp = load %struct.dim2** %g.addr              ; <%struct.dim2*>
>>> [#uses=1]
>>>  %tmp1 = bitcast %struct.dim2* %retval to i8*    ; <i8*> [#uses=1]
>>>  %tmp2 = bitcast %struct.dim2* %tmp to i8*       ; <i8*> [#uses=1]
>>>  call void @llvm.memcpy.i64(i8* %tmp1, i8* %tmp2, i64 8, i32 4)
>>>  %0 = bitcast %struct.dim2* %retval to double*   ; <double*> [#uses=1]
>>>  %1 = load double* %0, align 1                   ; <double> [#uses=1]
>>>  ret double %1
>>> }
>>> 
>>> declare void @llvm.memcpy.i64(i8* nocapture, i8* nocapture, i64, i32)
>>> nounwind
>>> -------------------------------------------------
>>> 
>>> What I want to see is the exactly same signature of the function named
>>> "kernel" as in the source code.
>>> 
>>> Let me know if I'm doing anything wrong.
>>> 
>>> Thanks,
>>> Naoya
>>> 
>>> On Wed, Mar 24, 2010 at 8:58 PM, Renato Golin <rengolin at systemcall.org>
>>> wrote:
>>>> On 24 March 2010 07:34, Naoya Maruyama <naoya.maruyama at gmail.com> wrote:
>>>>> However, for example, with Clang, if a function
>>>>> returns struct {float, float}, then the compiled function in the llvm
>>>>> bitcode returns a double that aggregates the two floats.
>>>> 
>>>> It's completely wrong to convert { float, float } into double. Just
>>>> because they have the same size doesn't mean they're identical.
>>>> 
>>>> Can you give us a simple example where this occurs?
>>>> 
>>>> 
>>>> --
>>>> cheers,
>>>> --renato
>>>> 
>>>> http://systemcall.org/
>>>> 
>>>> Reclaim your digital rights, eliminate DRM, learn more at
>>>> http://www.defectivebydesign.org/what_is_drm
>>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev