> > So in neither of those scenarios testing maxsize=minsize alone makes too
> > much sense to me... What was the original motivation for differentiating
> > between precisely known size?
There is a case that could meet small maxsize. https://godbolt.org/z/489Tf7ssj
typedef unsigned char e_u8;
#d
On Wed, Mar 31, 2021 at 10:43 AM Jan Hubicka wrote:
>
> > > Reading through the optimization manual it seems that mosvb is fast for
> > > small block no matter if the size is hard wired. In that case you
> > > probably want to check whetehr max_size or expected_size is known to be
> > > small rath
> > Reading through the optimization manual it seems that mosvb is fast for
> > small block no matter if the size is hard wired. In that case you
> > probably want to check whetehr max_size or expected_size is known to be
> > small rather than max_size == min_size and both being small.
> >
> > But
On Wed, Mar 31, 2021 at 6:47 AM Jan Hubicka wrote:
>
> > > >
> > > > Patch is OK now. I was wondering about using avx256 for moves of known
> > >
> > > Done. X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is in now. Can
> > > you take a look at the patch for Skylake:
> > >
> > > https://gcc.gnu.org/pi
> > >
> > > Patch is OK now. I was wondering about using avx256 for moves of known
> >
> > Done. X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is in now. Can
> > you take a look at the patch for Skylake:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567096.html
>
> I was wondering, i
> >
> > Patch is OK now. I was wondering about using avx256 for moves of known
>
> Done. X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is in now. Can
> you take a look at the patch for Skylake:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567096.html
I was wondering, if CPU preffers rep
On Wed, Mar 31, 2021 at 1:05 AM Jan Hubicka wrote:
>
> > > It looks like X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is quite obviously
> > > benefical and independent of the rest of changes. I think we will need
> > > to discuss bit more the move ratio and the code size/uop cache polution
> > > issues
> > It looks like X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB is quite obviously
> > benefical and independent of the rest of changes. I think we will need
> > to discuss bit more the move ratio and the code size/uop cache polution
> > issues - one option would be to use increased limits for -O3 only.
>
On Tue, Mar 23, 2021 at 12:59 AM H.J. Lu via Gcc-patches
wrote:
>
> On Mon, Mar 22, 2021 at 7:10 AM Jan Hubicka wrote:
> >
> > >
> > > gcc/
> > >
> > > * config/i386/i386-expand.c (expand_set_or_cpymem_via_rep):
> > > For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, don't convert QImode
> > >
On Mon, Mar 22, 2021 at 4:57 PM H.J. Lu wrote:
>
> On Mon, Mar 22, 2021 at 7:10 AM Jan Hubicka wrote:
> >
> > >
> > > gcc/
> > >
> > > * config/i386/i386-expand.c (expand_set_or_cpymem_via_rep):
> > > For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, don't convert QImode
> > > to SImode.
10 matches
Mail list logo
