This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/70308] memset generates rep stosl instead of rep stosq
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 22 Mar 2016 11:49:42 +0000
- Subject: [Bug middle-end/70308] memset generates rep stosl instead of rep stosq
- Auto-submitted: auto-generated
- References: <bug-70308-4 at http dot gcc dot gnu dot org/bugzilla/>
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?