This is the mail archive of the 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]

Re: bzero optimization rarely does

Hi Kaveh,
> > 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.


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