This is the mail archive of the
mailing list for the GCC project.
Re: bzero optimization rarely does
- From: Roger Sayle <roger at eyesopen dot com>
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Cc: <gcc at gcc dot gnu dot org>, <hp at bitrange dot com>, <pkoning at equallogic dot com>, <rth at redhat dot com>
- Date: Fri, 12 Jul 2002 17:03:57 -0600 (MDT)
- Subject: Re: bzero optimization rarely does
> > The problem is that the backend has control over the decision of
> > whether to call memset or to use a sequence of clear instructions.
> > So for example, in ns32k.h the "#define MOVE_RATIO 0" means that
> > this platform always calls memset!
> I thought the point of your patch was to divorce memset from
Perhaps, its better described as marrying memcpy with MOVE_RATIO
and memset with CLEAR_RATIO. It might still be reasonable for
a backend to "#define CLEAR_RATIO 0" to always force the use of
memset, much like "#define MOVE_RATIO 0" forces a call to memcpy.
I'm hesitant about breaking the symmetry between these two target
macros (artifically restricting backends) just to enable testing.
> I know it seems like a pain, but in the end IMHO it's worth it
> because then the regression checker ensures it's never broken
> ever again.
The problem is that the code was never "broken", just less
efficient. There were no user visible effects without examining
the assembly ouput, which was why no-one on powerpc, pa-risc
or mips has noticed until now.
I'm just unsure of how to portably test how memset and memcpy
are expanded, without restricting the currently available
functionality. [Perhaps thats a reasonable thing to do?].
Can you think of a test that will still work when and if the
ns32k backend decides to "#define CLEAR_RATIO 0"?
I believe in the benefits of the testsuite (my many contributions
to it should prove that). But I'm also unable to come up with
a portable test to determine whether the loop unrolling pass has
been acidentally disabled.