https://github.com/smithp35 commented:
Apologies for the delay in responding.
I don't have much to add over davemgreen and ostannard.
Leaving aside whether this should be an error in the front or back-end. As
mentioned before I haven't worked in this area for a long time, and there are
enough test changes here that make me nervous enough that this is going to
break some existing use cases. Some do look like sloppy triple selection,
although a lot of the tests don't use any floating point so it could be seen as
harsh to fault them. If I understood the area better that wouldn't be a
problem, but as I'm not enthusiastic about moving a diagnostic to the backend,
this isn't a change that I am best placed to approve. I won't object if there's
a consensus in the other direction.
One use case I'd want to keep working is where we have two functions in the
same object that are hardfp with hardware registers, and soft (with or without
hardware registers). Something like:
```
__attribute__((target("arch=cortex-m33"))) __attribute__((pcs("aapcs-vfp")))
float f1(float a, float b) {
return a + b;
}
__attribute__((target("arch=cortex-m0"))) __attribute__((pcs("aapcs"))) float
f2(float a, float b) {
return a + b;
}
```
There are some source files that do run-time selection based on hardware
detection.
https://github.com/llvm/llvm-project/pull/111334
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
