RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: Richard Sandiford [mailto:rdsandif...@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
Re: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
Thomas Preud'homme thomas.preudho...@arm.com writes: From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Thomas Preud'homme thomas.preudho...@arm.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? 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. 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? 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. Thanks, Richard
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Thomas Preud'homme thomas.preudho...@arm.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 [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
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Joseph S. Myers The functions affected use floating-point in their public interfaces - for example, __muldc3. Note that libcalls have a different hook (TARGET_LIBCALL_VALUE, ending up using arm_libcall_uses_aapcs_base) from the ones you mentioned. But if you use only functions that pass arm_libcall_uses_aapcs_base (i.e. the floating-point operations defined in RTABI) or don't involve floating point, then you can be compatible with both calling conventions. Thanks for the input Joseph and sorry for taking so long to reply. So I checked for the case of __mul* function and I believe there shouldn't be a problem as ARM backend never generate any call to these functions (at least according to my grep). Therefore, the only way these functions could end up being used is if a programmer explicitely call it after declaring its prototype and in such a case the call would appear in gcc as a normal function call and would thus be catched by the checks for normal (non libcall) inter compilation unit function call. I need to check however that all functions defined by libgcc fall in the same category as __mul* functions. With regards to TARGET_LIBCALL_VALUE, I will only have to consider it if there exist some libcall function where the calling convention is decided by the compiler. If all libgcc functions not in the ARM runtime ABI are like __mul, it shouldn't be a problem. Of course, all this is only true for ARM, things would be different for avr for instance (backend generates call to __mul* functions). Best regards, Thomas Preud'homme
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: Richard Sandiford [mailto:rdsandif...@googlemail.com] -mno-float as it stands today is really just -msoft-float with some floating-point support removed from the library to save space. One of the important examples is that the floating-point printf and scanf formats are not supported, so printf and scanf do not pull in large parts of the software floating-point library. Reading again your email I realized I had missed the best bits of this paragraph. Being able to avoid linking all the support for float in printf and scanf when it is not needed is indeed interesting for embedded use. How does this work by the way? Note that this is an orthogonal issue to the calling convention being used or the use of a FPU. I'll take the example of ARM as it's the one I know best (forgive me if you already know all these details). On ARM, the calling convention for variadic function states that all parameters of primitive type are either passed in GP registers or on the stack, no matter what is their type. That is, you cannot determine whether the float logic of scanf and printf is needed based on the type or parameters. You could have a float passed to printf but only its hexadecimal value being displayed by a %x printf modifier, for instance if you are trying to debug a software implementation of float arithmetic. On the opposite, you could pass an integer and display it as a float, for the same reason of debugging a software implementation of float arithmetic. As to the use of an FPU, consider the case of the -mfloat-abi=softfp switch on ARM target. It makes gcc generate instructions using the FPU to do float arithmetic but still passes float in GP registers for compatibility with systems without an FPU. You can thus see that use of FPU, calling convention and linking float code of printf/scanf or 3 separate issues. The -no-float switch on MIPS seems to conflate these 3 issues by telling gcc not to do any float arithmetic (-nofpu, like if there was a -mfpu=none), that as a consequence the calling convention used does not matter (the thing for which I would like a switch to check that fact and an automatic detection) and that float related code of printf/scanf should not be linked in (this could be useful for other target used in embedded scenarios). Since these three aspects could be useful to several architectures I think they should be implemented in arch independent code. 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. A last word about the linking issue. It would be nice to detect the need for float part of printf/scan automatically. However, I don't think it is possible to detect all cases because, as explained above, you can't deduce what will be displayed based on the type of the parameter. The only reliable way is to parse the format string but if the format string is not hardcoded but constructed then there is nothing you can do. However if all call to printf have a hardcoded format string (should be the case for most programs) then you can say for certain that the float code does not need to be linked. For program where this automatic detection is too conservative it would then still be possible to use the switch to force the float code to be left out. Best regards, Thomas Preud'homme
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
On Tue, 18 Mar 2014, Thomas Preud'homme wrote: From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Joseph S. Myers The functions affected use floating-point in their public interfaces - for example, __muldc3. Note that libcalls have a different hook (TARGET_LIBCALL_VALUE, ending up using arm_libcall_uses_aapcs_base) from the ones you mentioned. But if you use only functions that pass arm_libcall_uses_aapcs_base (i.e. the floating-point operations defined in RTABI) or don't involve floating point, then you can be compatible with both calling conventions. Thanks for the input Joseph and sorry for taking so long to reply. So I checked for the case of __mul* function and I believe there shouldn't be a problem as ARM backend never generate any call to these functions (at least according to my grep). Therefore, the only way these functions could end up being used is It's not the backend that generates calls to most libgcc functions, but the core compiler (when the optabs don't define a way of expanding some operation inline), which will happily generate calls to __muldc3 on ARM for multiplication of double _Complex values. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
Thomas Preud'homme thomas.preudho...@arm.com writes: From: Richard Sandiford [mailto:rdsandif...@googlemail.com] -mno-float as it stands today is really just -msoft-float with some floating-point support removed from the library to save space. One of the important examples is that the floating-point printf and scanf formats are not supported, so printf and scanf do not pull in large parts of the software floating-point library. Reading again your email I realized I had missed the best bits of this paragraph. Being able to avoid linking all the support for float in printf and scanf when it is not needed is indeed interesting for embedded use. How does this work by the way? -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. Note that this is an orthogonal issue to the calling convention being used or the use of a FPU. I'll take the example of ARM as it's the one I know best (forgive me if you already know all these details). Well, maybe orthogonal in concept, but as above, not in implementation :-) -mno-float really means does not use floating point in any form, so has a stricter requirement than what you wanted. On ARM, the calling convention for variadic function states that all parameters of primitive type are either passed in GP registers or on the stack, no matter what is their type. That is, you cannot determine whether the float logic of scanf and printf is needed based on the type or parameters. You could have a float passed to printf but only its hexadecimal value being displayed by a %x printf modifier, for instance if you are trying to debug a software implementation of float arithmetic. On the opposite, you could pass an integer and display it as a float, for the same reason of debugging a software implementation of float arithmetic. As to the use of an FPU, consider the case of the -mfloat-abi=softfp switch on ARM target. It makes gcc generate instructions using the FPU to do float arithmetic but still passes float in GP registers for compatibility with systems without an FPU. You can thus see that use of FPU, calling convention and linking float code of printf/scanf or 3 separate issues. The -no-float switch on MIPS seems to conflate these 3 issues by telling gcc not to do any float arithmetic (-nofpu, like if there was a -mfpu=none), that as a consequence the calling convention used does not matter (the thing for which I would like a switch to check that fact and an automatic detection) and that float related code of printf/scanf should not be linked in (this could be useful for other target used in embedded scenarios). Since these three aspects could be useful to several architectures I think they should be implemented in arch independent code. Definitely. The reason -mno-float is restricted to certain MIPS configurations rather than being a general MIPS option is because the current option is a hack. It ought to offer at least some help in enforcing the restrictions, whereas instead it just allows any floating-point operations to be used and compiles them in the same way as -msoft-float. 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. 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. A last word about the linking issue. It would be nice to detect the need for float part of printf/scan automatically. However, I don't think it is possible to detect all cases because, as explained above, you can't deduce what will be displayed based on the type of the parameter. The only reliable way is to parse the format string but if the format string is not hardcoded but constructed then there is nothing you can do. Agreed. However if all call to printf have a hardcoded format string (should be the case for most programs) then you can say for certain that the float code does not need to be linked. For program where this automatic detection is too conservative it would then still be possible to use the switch to force the float code to be left out. I agree it's possible. FWIW, as things stand, MIPS just treats hard-float and soft-float code as link-incompatible, so I don't think we could use it there. Thanks, Richard
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: Thomas Preud'homme [Since I can now send emails without disclaimers, I registered to the mailing list with my work email. Thus no need to CC me anymore.] Failed in the previous 2 emails. Sorry about that.
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
[Since I can now send emails without disclaimers, I registered to the mailing list with my work email. Thus no need to CC me anymore.] My apologize for the line length, the MUA says it all I think. It seems to ignore my word wrap setting From: Joseph Myers [mailto:jos...@codesourcery.com] Sent: Wednesday, March 05, 2014 2:13 AM If the function is only declared and not called or defined (in a system header etc.), of course you don't want that to affect the ABI (even in the case of an inline function in a system header, unless an out-of-line call is generated to it). But a call to a function not defined in that unit does affect the ABI compatibility, if the call involves affected types. This should be fine with the current implementation as I did the check inside the hooks TARGET_FUNCTION_ARG, TARGET_FUNCTION_VALUE and INIT_CUMULATIVE_ARG. The two former allow to test whether a parameter or a return value is a float while the latter is used to test whether the float ABI actually matters. INIT_CUMULATIVE_ARG is called when knowing where a parameter ends up matters, so when a function is defined (not declared) or when it is called. Checking whether the function is static or variadic allow to have a complete check. Inlining does not need any additional check since if the function is inlined there is no call and if not there will be a call and the current checks will catch it. However, one thing I did not do is look in function calls if the return value is ignored or not. If it is ignored the float ABI does not matter. Some libgcc functions on ARM have ABIs that depend on which AAPCS variant is in use - that is, libcalls, not just explicitly defined or called functions, can affect the ABI compatibility. But the RTABI functions don't - if you allow for that, then you increase the number of cases that end up compatible with both ABI variants. Do you have some example of such libgcc functions? Is there any of them with no link to the use of float in public interface? Without knowing any such case from the top of my head I would say that the use of any of these functions make the compilation unit not compatible with both calling conventions since it requires libgcc for a specific calling convention but maybe the runtime library can be treated differently than other libraries. On ARM, variadic functions use only the base AAPCS and so don't affect compatibility even if they have floating-point (or vector) arguments. (This is something that's different on some other architectures with similar issues.) Yep I took this into consideration. Best regards, Thomas
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Yeah, that'd be great. The checking that MIPS's -mno-float should do (but doesn't do) would be a superset of what you need, since the MIPS case would include internal uses of floats. But it would definitely make sense to share the bits that can be shared and (for example) to get consistent error messages for them. I agree on the error messages and on a common switch. I am not sure for the rest though (see below). How about warning for all float types (as the float option) and all vector types (as a separate option)? I'm not sure there's as much value in warning specifically about hardware types since that can always change in future. E.g. a while ago the only MIPS vector of interest was V2SF, but then Loongson added some integer ones, and now MSA is adding 128-bit vector types. There could be wider types in future, as happened for 512-bit AVX. I do not think it is a good approach. First, it means on ARM a user would need to use several switches to test compatibility and at least one part would be ARM specific (vector of less than 4 float/double). Second, when the function is variadic ARM use the base calling convention, no matter what is the calling convention normally used. So a float in a variadic function is not a problem for ARM but might be a problem for MIPS. I agree though that there is an overlap with the -no-float switch of MIPS. On the other hand checking for the dual compatibility of an ARM code is just about 15 lines of code and doing this in middle end with some hooks for architecture specific bits would make the code much bigger I think. I'll think some more about it and give you a more decided opinion. Right now my mind is not set. -mno-float as it stands today is really just -msoft-float with some floating-point support removed from the library to save space. One of the important examples is that the floating-point printf and scanf formats are not supported, so printf and scanf do not pull in large parts of the software floating-point library. But the restrictions that apply to -mno-float should make it link-compatible with -mhard-float too, as for your use case. Right. With your explanation and the description of the -mno-float switch I now understand what it does. So as I said, there is an important overlap with my work and if I can find an approach that manage to share some code I will do that. I am unsure at present about whether it is a good thing to do. I believe a new switch is necessary since what I need for ARM is slightly different than -mno-float meaning. The logic could be partially shared if it is not too complicated to do so. Best regards, Thomas
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
On Wed, 5 Mar 2014, Thomas Preud'homme wrote: Some libgcc functions on ARM have ABIs that depend on which AAPCS variant is in use - that is, libcalls, not just explicitly defined or called functions, can affect the ABI compatibility. But the RTABI functions don't - if you allow for that, then you increase the number of cases that end up compatible with both ABI variants. Do you have some example of such libgcc functions? Is there any of them with no link to the use of float in public interface? Without knowing any such case from the top of my head I would say that the use of any of these functions make the compilation unit not compatible with both calling conventions since it requires libgcc for a specific calling convention but maybe the runtime library can be treated differently than other libraries. The functions affected use floating-point in their public interfaces - for example, __muldc3. Note that libcalls have a different hook (TARGET_LIBCALL_VALUE, ending up using arm_libcall_uses_aapcs_base) from the ones you mentioned. But if you use only functions that pass arm_libcall_uses_aapcs_base (i.e. the floating-point operations defined in RTABI) or don't involve floating point, then you can be compatible with both calling conventions. -- Joseph S. Myers jos...@codesourcery.com
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
Hi Thomas, Do you particularly need a switch for this? You could view this as simply relaxing the ABI requirements of a module, a switch would only serve to enforce the need for a compatible ABI and error if not. If you build something for a soft-float ABI and never actually trigger any of the soft-float specific parts of the ABI then you could safely mark the module as no-float ABI (same for hard-float). A simple check would be if floating point types are used in parameters or returns but actually it could be more refined still if none of the arguments or returns would be passed differently between the ABI types. The problem with relaxing the ABI is that you only know whether it can be relaxed at the end of compiling all functions, I am currently doing some work for MIPS where the assembler will be calculating overall requirements based on an initial setting and then analysis of the code in the module. To relax a floating point ABI I would expect to emit an ABI attribute at the head of a file, which is either soft or hard float, but then each function would get an attribute to say if it ended up as a compatible ABI. If all global functions say compatible then the module can be relaxed to be a compatible FP ABI. I think the ability to detect the case of generating ABI agnostic code would be useful for other architectures too. MIPS does have an option for something similar to this which is -mno-float but it does not really do what you are aiming for here. The -mno-float option marks a module as float ABI agnostic but actually performs code gen for a soft-float ABI. It is up to the programmer to avoid floating point in function signatures. Perhaps this option would be useful to support the enforced compatible ABI but being able to relax the ABI is better still as it would require no effort from the end user. I'm planning on proposing these kind of changes for MIPS in the near future. Regards, Matthew -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Thomas Preudhomme Sent: 04 March 2014 07:02 To: gcc@gcc.gnu.org Subject: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat [Please CC me as I'm not subscribed to this list] Hi there, I'm currently working on adding a switch to check whether public function involve float parameters or return values. Such a check would be useful for people trying to write code that is compatible with both base standard (softfloat) and standard variant (hardfloat) ARM calling convention. I also intend to set the ELF attribute Tag_ABI_VFP_args to value 3 (code compatible with both ABI) so this check would allow to make sure such value would be set. I initially thought about reusing -mfloat-abi with the value none for that purpose since it would somehow define a new ABI where no float can be used. However, it would then not be possible to forbit float in public interface with the use of VFP instructions for float arithmetic (softfp) because this switch conflates the float ABI with the use of a floating point unit for float arithmetic. Also, gcc passes -mfloat-abi down to the assembler and that would mean teaching the assembler about - mfloat-abi=none as well. I thus think that a new switch would be better and am asking for your opinion about it as I would like this functionality to incorporate gcc codebase. Best regards, Thomas Preud'homme
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
Le 2014-03-04 19:14, Matthew Fortune a écrit : Hi Thomas, Hi Matthew, Do you particularly need a switch for this? You could view this as simply relaxing the ABI requirements of a module, a switch would only serve to enforce the need for a compatible ABI and error if not. If you build something for a soft-float ABI and never actually trigger any of the soft-float specific parts of the ABI then you could safely mark the module as no-float ABI (same for hard-float). I was maybe not clear enough but my patch already has this logic to detect whether any float is used at all and emit an elf attribute accordingly. However, someone who wants to be compatible with both softfloat and hardfloat would need to look at the output to see that was achieved. Such a switch would allow people to actually ensure that they managed to create a float agnostic ABI. A simple check would be if floating point types are used in parameters or returns but actually it could be more refined still if none of the arguments or returns would be passed differently between the ABI types. The problem with relaxing the ABI is that you only know whether it can be relaxed at the end of compiling all functions, I am currently doing some work for MIPS where the assembler will be calculating overall requirements based on an initial setting and then analysis of the code in the module. To relax a floating point ABI I would expect to emit an ABI attribute at the head of a file, which is either soft or hard float, but then each function would get an attribute to say if it ended up as a compatible ABI. If all global functions say compatible then the module can be relaxed to be a compatible FP ABI. Right. It's actually quite simple. As soon as you meet a function which passes or returns a float then you can mark the whole module as not agnostic and fall back to the usual behavior. If you arrive at the end of a compiling unit without encoutering such a case then you are agnostic. You could mark each function individually but I don't think it's necessary to go that far. If you want only some functions to be compatible you could put them in a separate file. My current patch goes a bit beyond than this in that it only care about public interface. Call withing one module can use whatever calling convention they want, it does not change the ABI. I think the ability to detect the case of generating ABI agnostic code would be useful for other architectures too. I do not know the other architecture to know if that is the case but according to what you said for MIPS it seems to be the case. Right now I implemented it completely in the backend but that can be done in middle end if several architecture would benefit from it. I did not do it because I thought that other architecture might care more about different kind of ABI like the calling convention for long long on 32 bit architectures or structure or bitfield. I did not know if the calling convention for float parameter mattered to other architecture. Also in the case of ARM a structure of up to 4 floats/double would be passed via float registers so that would be counted as a float but maybe not for MIPS. So a common switch for several architecture might be strange if each interpret it in a different way. MIPS does have an option for something similar to this which is -mno-float but it does not really do what you are aiming for here. The -mno-float option marks a module as float ABI agnostic but actually performs code gen for a soft-float ABI. It is up to the programmer to avoid floating point in function signatures. Perhaps this option would be useful to support the enforced compatible ABI but being able to relax the ABI is better still as it would require no effort from the end user. I'm planning on proposing these kind of changes for MIPS in the near future. Yeah that's different to no-float here since the body of functions can use float arithmetic and even function interface as long as they are not public. I am interesting in knowing what exactly is your use case, what is the difference for the calling convention with regards to float on MIPS architecture. Maybe it's just a matter to choose the right name for the switch such as -mabi-agnostic or something? Anyway, thanks for your comment on this issue. It is good to know that there might be some other uses than just ARM. Regards, Matthew Best regards, Thomas
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
On Wed, 5 Mar 2014, Thomas Preudhomme wrote: Right. It's actually quite simple. As soon as you meet a function which passes or returns a float then you can mark the whole module as not agnostic and fall back to the usual behavior. If you arrive at the end of a compiling unit without encoutering such a case then you are agnostic. You could mark each function individually but I don't think it's necessary to go that far. If you want only some functions to be compatible you could put them in a separate file. My current patch goes a bit beyond than this in that it only care about public interface. Call withing one module can use whatever calling convention they want, it does not change the ABI. If the function is only declared and not called or defined (in a system header etc.), of course you don't want that to affect the ABI (even in the case of an inline function in a system header, unless an out-of-line call is generated to it). But a call to a function not defined in that unit does affect the ABI compatibility, if the call involves affected types. Some libgcc functions on ARM have ABIs that depend on which AAPCS variant is in use - that is, libcalls, not just explicitly defined or called functions, can affect the ABI compatibility. But the RTABI functions don't - if you allow for that, then you increase the number of cases that end up compatible with both ABI variants. On ARM, variadic functions use only the base AAPCS and so don't affect compatibility even if they have floating-point (or vector) arguments. (This is something that's different on some other architectures with similar issues.) -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
Thomas Preudhomme robo...@celest.fr writes: I think the ability to detect the case of generating ABI agnostic code would be useful for other architectures too. I do not know the other architecture to know if that is the case but according to what you said for MIPS it seems to be the case. Right now I implemented it completely in the backend but that can be done in middle end if several architecture would benefit from it. Yeah, that'd be great. The checking that MIPS's -mno-float should do (but doesn't do) would be a superset of what you need, since the MIPS case would include internal uses of floats. But it would definitely make sense to share the bits that can be shared and (for example) to get consistent error messages for them. I did not do it because I thought that other architecture might care more about different kind of ABI like the calling convention for long long on 32 bit architectures or structure or bitfield. I did not know if the calling convention for float parameter mattered to other architecture. Also in the case of ARM a structure of up to 4 floats/double would be passed via float registers so that would be counted as a float but maybe not for MIPS. So a common switch for several architecture might be strange if each interpret it in a different way. How about warning for all float types (as the float option) and all vector types (as a separate option)? I'm not sure there's as much value in warning specifically about hardware types since that can always change in future. E.g. a while ago the only MIPS vector of interest was V2SF, but then Loongson added some integer ones, and now MSA is adding 128-bit vector types. There could be wider types in future, as happened for 512-bit AVX. MIPS does have an option for something similar to this which is -mno-float but it does not really do what you are aiming for here. The -mno-float option marks a module as float ABI agnostic but actually performs code gen for a soft-float ABI. It is up to the programmer to avoid floating point in function signatures. Perhaps this option would be useful to support the enforced compatible ABI but being able to relax the ABI is better still as it would require no effort from the end user. I'm planning on proposing these kind of changes for MIPS in the near future. Yeah that's different to no-float here since the body of functions can use float arithmetic and even function interface as long as they are not public. I am interesting in knowing what exactly is your use case, what is the difference for the calling convention with regards to float on MIPS architecture. Maybe it's just a matter to choose the right name for the switch such as -mabi-agnostic or something? -mno-float as it stands today is really just -msoft-float with some floating-point support removed from the library to save space. One of the important examples is that the floating-point printf and scanf formats are not supported, so printf and scanf do not pull in large parts of the software floating-point library. But the restrictions that apply to -mno-float should make it link-compatible with -mhard-float too, as for your use case. Thanks, Richard
