[LLVMdev] IR type safety
Andrew Lenharth
andrewl at lenharth.org
Tue Sep 21 10:39:43 PDT 2010
On Tue, Sep 21, 2010 at 12:27 PM, Renato Golin <rengolin at systemcall.org> wrote:
> On 21 September 2010 17:48, Devang Patel <dpatel at apple.com> wrote:
>> In the combined llvm IR, @p3 and @p won't match as expected.
>
> Hi Devang,
>
> That's not quite what I was thinking... Maybe I explained badly...
>
> Imagine this:
>
> -- a.ll --
> %struct.x = type { i32, i32 }
>
> %a = call void @func (%struct.x %b)
>
> -- b.ll --
> %struct.y = type { i32, i32 }
>
> declare i32 @func (%struct.y)
>
> Now, imagine that X and Y are completely different structures, they
> don't reflect the same type in the code, but in the IR it got
> flattened out, so the modules can't distinguish between X or Y.
>
> If I distribute IR (with the same data layout, target triple, etc),
> and you try to link against it, it will allow you to put apples in
> place of bananas...
>
> Does it make sense?
Type names don't have meaning. If you want this not to happen, you
can generate a different opaque type for each type in your language to
prevent merging.
Andrew
> --
> cheers,
> --renato
>
> http://systemcall.org/
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
More information about the llvm-dev
mailing list