This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New prologue/epilogue code for i386 string functions
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org, neleai at seznam dot cz
- Date: Wed, 23 Oct 2013 11:06:46 +0200
- Subject: Re: New prologue/epilogue code for i386 string functions
- Authentication-results: sourceware.org; auth=none
- References: <20131022155844 dot GA6049 at kam dot mff dot cuni dot cz> <87a9i0tln1 dot fsf at tassilo dot jf dot intel dot com>
> Jan Hubicka <hubicka@ucw.cz> writes:
>
> > +static void
> > +expand_set_or_movmem_prologue_epilogue_by_misaligned_moves (rtx destmem, rtx srcmem,
> > + rtx *destptr, rtx *srcptr,
> > + enum machine_mode mode,
> > + rtx value, rtx vec_value,
> > + rtx *count,
> > + rtx *done_label,
> > + int size,
> > + int desired_align,
> > + int align,
> > + unsigned HOST_WIDE_INT *min_size,
> > + bool dynamic_check,
> > + bool
> > issetmem)
>
> That's a scary prototype. Could you refactor this somehow to not need
> that many parameters? Perhaps this should be multiple functions.
Well, it became worse with merging memcpy and memset code (but not by that much).
The problem here is that the prologue/epilogue code does really quite a lot of things
at once.
It sort of naturally split into the code handling small memcpy and the branchless code
copying first and last N bytes. I can split the function this way, but I think the
first one will take pretty much all the existing parameters...
I will try to look into this...
Honza
>
> -Andi
>
> --
> ak@linux.intel.com -- Speaking for myself only