This is the mail archive of the
mailing list for the GCC project.
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
- From: "Thomas Preud'homme" <thomas dot preudhomme at arm dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Fri, 21 Mar 2014 14:39:02 +0800
- Subject: RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
- Authentication-results: sourceware.org; auth=none
- References: <873b32b6c5ab5233abff5083d7e7f57a at celest dot fr> <6D39441BF12EF246A7ABCE6654B023534B53F7 at LEMAIL01 dot le dot imgtec dot org> <93929e2462c9db9ad544a5fa33f91388 at celest dot fr> <87vbvtbzcc dot fsf at talisman dot default> <001c01cf428a$e9217dc0$bb647940$ at arm dot com> <87ha6vgxhv dot fsf at talisman dot default>
> From: Richard Sandiford [mailto:firstname.lastname@example.org]
> "Thomas Preud'homme" <email@example.com> 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  and back end would modify.
 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
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?