search for: hfas

...ake writing an ABI-compliant front-end as easy as possible. After that it should aim to have a sane ABI for hand-written LLVM code, and finally it should try to follow the ABI itself where possible (the last two are possibly interchangeable, but the first is primary). The current situation with HFAs is that, without changes to make the backend aware of the concept, the front-end needs to know the entire sequence of previous arguments and how LLVM lowers them to work out how to pass an HFA correctly. The goal I'd like to see reached is that a front-end should be able to map one of its...

...ew (for both our uses). It's also information that's readily available when InputArg/OutputArgs are being constructed. In your case: CCIf<"SourceTy->isPointerTy()", CCAssignToReg<[P1, P2]>>; I've got a patch which implements it for ARM and X86 (though not HFAs using the features yet, I'm still musing on the best interface to present there -- "HFA* byval" for target simplicity or "HFA" for user simplicity), I'll see if I can clean it up for other targets and send it for comparison. The main issue with my approach is that sp...

...ould be bludgeoned to mean "this is an HFA, put it in VFP regs", but it would be unspeakably ugly. I believe that if the LLVM original Type* pointer is exposed to TargetLowering (perhaps as part of InputArg/OutputArg), then LLVM itself can decide what to do with both Small Structures and HFAs in a sane manner: writing a front-end which adheres to the PCS would be much easier for any source language. The worry is the apparent layering violation by passing a Type* further down. But I'd argue that the TargetLowering functions involved are constructing a DAG from nothing rather than tra...

Hi all, I think that ABI of LLVM IR level is different from ABI on real architecture such as ARM or x86. ABI of LLVM IR level doesn't consider about register usage. It just describes parameters and padding information related to alignment of parameters. As Anton mentioned, LLVM have expressed ABI information on bitcode using front-end. If someone wants to maintain information from high level

Tim, > Opinions, anyone? (Hint hint). I think here stuff should be thought of from different points. While providing source type for argument might be beneficial, it might cause moving the code from frontend to backend. Consider e.g. passing struct by value including crazy padding inside. The ABI might specify that padding should be removed and struct is passed field-by-field. Also, note that

...ould be bludgeoned to mean "this is an HFA, put it in VFP regs", but it would be unspeakably ugly. I believe that if the LLVM original Type* pointer is exposed to TargetLowering (perhaps as part of InputArg/OutputArg), then LLVM itself can decide what to do with both Small Structures and HFAs in a sane manner: writing a front-end which adheres to the PCS would be much easier for any source language. The worry is the apparent layering violation by passing a Type* further down. But I'd argue that the TargetLowering functions involved are constructing a DAG from nothing rather than tra...

...9;s also information that's > readily available when InputArg/OutputArgs are being constructed. In your > case: > > CCIf<"SourceTy->isPointerTy()", CCAssignToReg<[P1, P2]>>; > > I've got a patch which implements it for ARM and X86 (though not HFAs using > the features yet, I'm still musing on the best interface to present there > -- "HFA* byval" for target simplicity or "HFA" for user simplicity), I'll > see if I can clean it up for other targets and send it for comparison. Here's the patch I was tal...

Hi Tim > I'm not sure I follow this point. Is preserving the source language a bad > thing for some reason I'm missing? Certainly, if it affects optimisation it > would be. Let's consider one example: union { float foo[4]; int bar[3]; }; This is definitely not a HFA. However, such a union can be represented via several different things in LLVM IR: [4 x float], [4 x