search for: byvalu

...example program: struct Guid { unsigned int Data1; unsigned short Data2; unsigned short Data3; unsigned char Data4[8]; }; struct Guid g = { 0x8faf43c9, 0x85e9, 0x41f9, { 0xbe, 0x42, 0x99, 0x96, 0x4, 0xe0, 0x85, 0xb3 } }; void v(int, ...); void byValue(void) { v(1, g); } void byReference(void) { v(1, &g); } And the disassembled output: _byValue: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp,%rbp 0000000000000004 subq $0x30,%rsp 0000000000000008 movq 0x00000008(%rip),%rax 000...

...   unsigned int    Data1; >      unsigned short  Data2; >      unsigned short  Data3; >      unsigned char   Data4[8]; >    }; > >    struct Guid g = { 0x8faf43c9, 0x85e9, 0x41f9, { 0xbe, 0x42, 0x99, 0x96, 0x4, 0xe0, 0x85, 0xb3 } }; > >    void v(int, ...); > >    void byValue(void) >    { >      v(1, g); >    } > >    void byReference(void) >    { >      v(1, &g); >    } > > And the disassembled output: > >    _byValue: >    0000000000000000    pushq   %rbp >    0000000000000001    movq    %rsp,%rbp >    0000000000000004...

...nions, e.g. to manipulate trees. Okay, so you're just talking about boxed vs unboxed discriminated unions, or "by ref" vs "by value" discriminated unions. Clearly the LLVM IR support for "c style unions" would only be useful for "unboxed" or "byvalue" discriminated unions. That doesn't mean that *your* specific uses would need them. If you're doing "by-ref" or "boxed" unions, then our current support should already be sufficient. -Chris

Hi, > I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. >From very quick test-cases with no understanding of XCore, that looks plausible. > LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). > This is where I placed the CCIfByVal<CCPassByVal<0,4>>

...should ideally be done early on in the IR in my thinking - to allow optimisation if the data is only ever read. FYI, the clang hack is - notice the "CreateMemCpy": CodeGenFunction::EmitFunctionProlog(){ ... if (ArgI.getIndirectByVal()) { llvm::AllocaInst *ByValue = CreateMemTemp(Ty, V->getName() + "agg.tmp"); llvm::ConstantInt * size = llvm::ConstantInt::get(IntPtrTy, getContext().getTypeSizeInChars(Ty).getQuantity()); Builder.CreateMemCpy(ByValue, V, size, 4 ); V = ByValue; // and point...

...ipulate trees. > > Okay, so you're just talking about boxed vs unboxed discriminated > unions, or "by ref" vs "by value" discriminated unions. Clearly the > LLVM IR support for "c style unions" would only be useful for > "unboxed" or "byvalue" discriminated unions. That doesn't mean that > *your* specific uses would need them. Yes. I expect relatively few people would need C-style unions. > If you're doing "by-ref" or "boxed" unions, then our current support should > already be sufficient....

Hi Tim, Thank you for the input. I think I follow you. I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. The LowerFormalArguments() is where I am stuck. LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). This is where I placed the CCIfByVal<CCPassByVal<0,4>> which

On Friday 02 January 2009 20:48:25 Chris Lattner wrote: > On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote: > >> Exactly. I'm not especially interested in C-style unions, I'm > >> interested in discriminated unions. But the actual discriminator field is > >> easily represented in LLVM IR already, so there's no need to extend the > >> IR to support

On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote: >> Exactly. I'm not especially interested in C-style unions, I'm >> interested >> in discriminated unions. But the actual discriminator field is easily >> represented in LLVM IR already, so there's no need to extend the IR >> to >> support them. That's why I am only asking for C-style union

On Tue, Oct 4, 2011 at 6:36 PM, Renato Golin <rengolin at systemcall.org> wrote: > Hi Talin, > > I too agree 100% with Dan's words, and this could be a good pointer > for Jin-Gu Kang to continue on his pursuit for a better > target-independent bitcode. > > Also, add your backwards compatibility issue to debug metadata in IR, > in which fields appear or disappear

Hi Talin, I too agree 100% with Dan's words, and this could be a good pointer for Jin-Gu Kang to continue on his pursuit for a better target-independent bitcode. Also, add your backwards compatibility issue to debug metadata in IR, in which fields appear or disappear without notice. But I think you hit a sweet spot here... On 4 October 2011 21:23, Talin <viridia at gmail.com> wrote: