https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120141
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|NEW |RESOLVED
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So we discussed this in the patchwork meeting this week. The consensus was
this is just how the intrinsics work. You should think of them as a fairly
direct mapping to assembly code and if (for example) you pass in a shift count
of zero, that's precisely the code they're going to generate.
As I mentioned before, the internal representation generated by the intrinsics
is not amenable to optimization by the generic optimizers in GCC. So expecting
the optimizers to clean this up just isn't reasonable.
We did discuss trying to optimize away these cases during initial RTL
generation from the intrinsic expanders, but the consensus was that was
ultimately a bad idea and would be a long term maintenance burden that only
helps poorly written intrinsic codes.
In short, this isn't going to be fixed. The intrinsic interface is working as
designed. If you want to avoid nop codes, then don't pass arguments that
result in nop operations to the intrinsics interfaces.
