[RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat

Thomas Preud'homme thomas.preudhomme@arm.com
Mon Mar 24 02:56:00 GMT 2014


> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
> 
> Yes.  The configurations that support -mno-float have separate -mno-float
> multilibs.  In a sense, the point of -mno-float instead of -msoft-float is
> to select these cut-down libraries.

IIRC, glibc loads some code on demand to achieve the goal of reducing the size of what is on memory. This does not require compiling the code in a special way.

> >
> > I don't know how exactly that would work. You would switch twice for
> > each function and ask the register used for each function call?
> 
> Yeah, that's the idea.  More generally, run initialize_argument_information
> once for each ABI and compare the two arg_data arrays.  Similarly for
> function.c.

It does not work with the pcs attribute though. When the attribute is set for a function, the default ABI is ignored and the one specified in the attribute is used instead. So even if you created 2 sub-targets (I hope it's the right term), the two calls to initialize_argument_information would return the same register for a float argument even since the attribute is used instead and you would miss the fact that the function might be float ABI dependent.

FYI, such a flag is used for some libgcc functions:

__fixdfi
__fixsfdi
__fixunssfdi
__fixunsdfdi

Also as you said, calling twice initialize_argument_information for each function call might be suboptimal, although that ought to be benchmarked.

Therefore I believe a new hook is necessary. For opted for a variable set by the backend whenever a function is float ABI dep but it is not a very elegant approach: the hook is very specific to this use case and uses a variable to communicate back and forth between backend and middleend. Thus I am open to suggestions for a better hook. Can a reverse hook be used (backend calling a function in middle end) by the way?

Best regards,

Thomas




More information about the Gcc mailing list