On Wed, Jul 31, 2024 at 10:24 AM Jakub Jelinek <[email protected]> wrote:
>
> On Wed, Jul 31, 2024 at 10:11:44AM +0200, Uros Bizjak wrote:
> > OK. Richard, can you please mention the above in the comment why
> > XFmode is rejected in the hook?
> >
> > Later, we can perhaps benchmark XFmode move vs. generic memory copy to
> > get some hard data.
>
> My (limited) understanding was that the hook would be used only for cases
> where we'd like to e.g. value number some SF/DF/XF etc. mode loads and some
> subsequent loads from the same address with different mode but same size
> the same and replace say int or long long later load with VIEW_CONVERT_EXPR
> of the result of the SF/SF mode load. That is what was incorrect, because
> the load didn't preserve all the bits. The patch would still keep doing
> normal SF/DF/XF etc. mode copies if that is all that happens in the program,
> load some floating point value and store it elsewhere or as part of larger
> aggregate copy.
So, the hook should allow everything besides SF/DFmode, simply:
switch (GET_MODE_INNER (mode))
{
case SFmode:
case DFmode:
/* These suffer from normalization upon load when not using SSE. */
return !(ix86_fpmath & FPMATH_387);
default:
return true;
}
Uros,
