This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> From: Richard Sandiford []
> "Thomas Preud'homme" <> writes:
> -mno-float causes gcc to define the macro __mips_no_float, which the
> implementation can use when deciding whether to bother handling %f, etc.
> I'm afraid there's nothing more sophisticated to it than that.

So the libc needs to be compiled with -mno-float as well so that printf and
scanf drop the float handling? 

> > In ARM case the calling convention also determine how to pass
> > structures of 4 or less floats/double so there would also be an
> > arch-dependent part. I am not sure about whether to add a new hook or
> > provide helper function in the middle end for the backend to use.
> I assume for most cases the restriction is of the form "calling this
> function must not use registers in class X".  I think we can detect
> that using the existing hooks.

I wish that information would be enough. Unfortunately, it's not.
Suppose your code is compiler with a soft float ABI. Then, your float do not
use any special register and yet, they make your code dependent on the
float ABI. Therefore, the real question you are asking the backend is:
"is the register allocation for this parameter dependent on the float ABI?".
I do not think any current hook gives you this information.

Ideally that would be a new version of the function_arg and function_value
hook that takes a pointer to a boolean variable for the backend to give this
information. Alternatively, it could be a new variable hook that the middle
end [0] and back end would modify.

[0] The middle end needs to be able to reset the variable to detect all the
function that break the compatibility instead of just the first one, unless
the variable is an integer that gets incremented.

> A more general restriction would be "must pass arguments in the same
> way for both option set A and option set B".  That too could be done
> using existing hooks and SWITCHABLE_TARGET, although it might not be
> hyper-efficient.

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?

Best regards,

Thomas Preud'homme

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]