Rick Mann
2013-Jan-20 09:57 UTC
[LLVMdev] Clang's approach to anonymous struct pointer parameters
For the following code: struct XBeePacket; typedef void (*CompletionProc)(XBeePacket* inPacket, void* inParam2); struct XBeePacket { bool mField1; CompletionProc mCompletionProc; }; Why does clang emit this IR? %struct.XBeePacket = type { i8, {}* } define void @MyCompletionProc(%struct.XBeePacket* %inPacket, i8* %inParam2) nounwind uwtable ssp { entry: ... } It makes the struct field for the completion proc an an anonymous aggregate pointer. Is that better than making the first parameter to MyCompletionProc void* or something similar? I guess there's no way in LLVM IR to forward-declare in a way that solves this, huh? -- Rick
Florian Brandner
2013-Jan-20 13:38 UTC
[LLVMdev] Clang's approach to anonymous struct pointer parameters
Hi Rick, this is a bug in Clang's LLVM-IR code generator: http://llvm.org/bugs/show_bug.cgi?id=14920 Best, Florian On Sunday, January 20, 2013 01:57:37 Rick Mann wrote:> For the following code: > > struct XBeePacket; > > typedef void (*CompletionProc)(XBeePacket* inPacket, void* inParam2); > > struct > XBeePacket > { > bool mField1; > CompletionProc mCompletionProc; > }; > > Why does clang emit this IR? > > %struct.XBeePacket = type { i8, {}* } > > define void > @MyCompletionProc(%struct.XBeePacket* %inPacket, i8* %inParam2) > nounwind uwtable ssp > { > entry: > ... > } > > It makes the struct field for the completion proc an an anonymous aggregate pointer. Is that better than making the first parameter to MyCompletionProc void* or something similar? > > I guess there's no way in LLVM IR to forward-declare in a way that solves this, huh? > >-- Florian Brandner Embedded Systems Engineering Group Department of Applied Mathematics and Computer Science Technical University of Denmark Richard Petersens Plads Building 322, room 206 2800 Lyngby Denmark phone: +45 45255223 web: http://www.imm.dtu.dk/~flbr/ email: flbr at imm.dtu.dk
Rick Mann
2013-Jan-20 16:06 UTC
[LLVMdev] Clang's approach to anonymous struct pointer parameters
On Jan 20, 2013, at 5:38, Florian Brandner <flbr at imm.dtu.dk> wrote:> Hi Rick, > > this is a bug in Clang's LLVM-IR code generator: > http://llvm.org/bugs/show_bug.cgi?id=14920Oh, interesting, thanks. How do I create a recursive definition like this?> > Best, > Florian > > On Sunday, January 20, 2013 01:57:37 Rick Mann wrote: >> For the following code: >> >> struct XBeePacket; >> >> typedef void (*CompletionProc)(XBeePacket* inPacket, void* inParam2); >> >> struct >> XBeePacket >> { >> bool mField1; >> CompletionProc mCompletionProc; >> }; >> >> Why does clang emit this IR? >> >> %struct.XBeePacket = type { i8, {}* } >> >> define void >> @MyCompletionProc(%struct.XBeePacket* %inPacket, i8* %inParam2) >> nounwind uwtable ssp >> { >> entry: >> ... >> } >> >> It makes the struct field for the completion proc an an anonymous aggregate pointer. Is that better than making the first parameter to MyCompletionProc void* or something similar? >> >> I guess there's no way in LLVM IR to forward-declare in a way that solves this, huh? > -- > Florian Brandner > Embedded Systems Engineering Group > Department of Applied Mathematics and Computer Science > Technical University of Denmark > Richard Petersens Plads > Building 322, room 206 > 2800 Lyngby > Denmark > > phone: +45 45255223 > web: http://www.imm.dtu.dk/~flbr/ > email: flbr at imm.dtu.dk > > >
Reasonably Related Threads
- [LLVMdev] Clang's approach to anonymous struct pointer parameters
- [LLVMdev] Calling dispatch_async() within call to ExecutionEngine::runFunction()
- [LLVMdev] Calling dispatch_async() within call to ExecutionEngine::runFunction()
- [LLVMdev] global control flow graph at machine code level
- [LLVMdev] global control flow graph at machine code level