Hi, On Fri, Oct 28, 2011 at 12:08:55AM +0200, Thomas Preud'homme wrote: > I've been reading arm-gen.c lately and was a bit surprised by some code > related to struct and float (including double and long double) parameter > passing in gfunc_call. It's probably just a mistake from my reading in which > case I'd appreciate you explained me the bits I missed. > > As I understand it [0], the array /plan/ is used to memorize the association > between parameters and the register(s) in which they are passed. The > association is done via a line plan[nb_args-1-i][1]=args_size/4; in a switch > case done in the second for loop browsing the parameter. > > [0] From lines like: > s=regmask(plan[nb_args-i-1][1]; and: > todo&=~(1<<plan[nb_args-i-1][1]) with TODO being used to generate ldm > instruction later. > > What bothers me is that the association is only done in the general case > (type > != float, double, long double and struct) but args_size is increased in > general > case *and* struct + floats case. This mean that if the first parameter of a > function is a structure of size 8 bytes, then core registers r0 and r1 are > skipped although they could be used by following integer parameter.
did you see the o(0xE8BD0000|todo); line further down? It pulls all parameters that should reside in core registers back from the stack right before calling the function. This includes structs and floats. > It's also in opposition to what require stage C in chapter 5.5 of AAPCS > documentation. Basically it says either a type qualify for co-processor > register in which case it's passed in co-processor register or on stack but > without touching NCRN (Next Core Register Number). Or it does not qualify for > co-processor register (for example if there is no co-processor like when tcc > produce code compatible with system without VFP, ie TCC_ARM_VFP is undefined) > and is allocated one or several core register (and can be half on registers > and half on stack). Values are simply not passed in floating point registers. That's how it was done with OABI on my Zaurus when I wrote gfunc_call and that's how it is done nowadays with EABI. TCC_ARM_VFP without TCC_ARM_EABI should ideally be equivalent to GCC with -mfpu=vfp -mfloat-abi=hard, but it isn't. I doubt anyone uses TCC if he is trading EABI compatibility for floating point performance. Best regards, Daniel _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel