tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Struct and float parameter passing ir arm-gen.c


From: Daniel Glöckner
Subject: Re: [Tinycc-devel] Struct and float parameter passing ir arm-gen.c
Date: Fri, 28 Oct 2011 01:19:50 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]