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? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
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 >
On 21 September 2010 18:39, Andrew Lenharth <andrewl at lenharth.org> wrote:> 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.Hi Andrew, Why create opaque types to avoid something that should be taken from granted (in a said "type-safe" representation)? I know it simplifies garbage collecting, but the GC could have a different view of the symbol table to achieve that (if that's feasible). Maybe I'm just underestimating the GC problem, or there could be an even stronger reason behind it, I don't know... Just tried this example in Clang: -- a.cpp -- struct Foo { int a; int b; }; int add(struct Foo f); int main() { struct Foo f = { 42, 10 }; return add(f); } ---- -- b.cpp -- struct Bar { int c; int d; }; int add(struct Bar b) { return b.c - b.d; } ---- In C++, with name mangling, you get a symbol error: Safe. In C, that compiles and return 32 (as expected): Safe again. So, assuming all languages conform to the C standard regarding structures, the IR is correct. In any other case, it's not. Am I being too picky? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm