This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/70308] memset generates rep stosl instead of rep stosq


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70308

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to UroÅ Bizjak from comment #4)
> The problem is actually in expr.c expanders, in this particular case
> set_storage_via_setmem expander. These expanders loop from narrowest mode to
> wider modes:
> 
>   for (mode = GET_CLASS_NARROWEST_MODE (MODE_INT); mode != VOIDmode;
>        mode = GET_MODE_WIDER_MODE (mode))
>     {
>       enum insn_code code = direct_optab_handler (setmem_optab, mode);
> 
>       if (code != CODE_FOR_nothing
>       ...
> 
> x86_64 declares "movmem<mode>" expander that defines both, movmemdi *AND*
> movmemsi on x86_64. Since the above loop expands narrowest mode first, it
> first checks movmemsi (which x86_64 uses as well).
> 
> Basing on the promise that wider-mode expanders are inherently faster, this
> is middle-end deficiency. Middle-end should reverse mode scanning loop to
> check wider modes first.
> 
> Adding some CCs.

Hmm, indeed.  Of course there is no way to iterate from largest to narrowest
mode...

Also one can only hope strict-align targets don't support expanding via
un-aligned larger modes then (though it will only fail "late" during
maybe_expand_insn then).

How is the changed behavior for x86 based on profile to explain btw?

I also wonder why the backend limits itself to emit SImode stores, it
can simply take the mode setmem is expanded with as a hint, no?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]