This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.1 Issues
- From: Andreas Jaeger <aj at suse dot de>
- To: Daniel Berlin <dan at dberlin dot org>
- Cc: Roger Sayle <roger at eyesopen dot com>, gcc-patches at gcc dot gnu dot org,Jakub Jelinek <jakub at redhat dot com>, Richard Henderson <rth at redhat dot com>,Mark Mitchell <mark at codesourcery dot com>,Dan Berlin <dan at cgsoftware dot com>
- Date: Sun, 10 Mar 2002 21:33:59 +0100
- Subject: Re: GCC 3.1 Issues
- References: <Pine.LNX.4.33.0203100550050.22459-100000@www.eyesopen.com><1015781395.2297.10.camel@localhost.localdomain>
Daniel Berlin <dan@dberlin.org> writes:
> On Sun, 2002-03-10 at 08:29, Roger Sayle wrote:
>>
>> Hi Andreas,
>> > I'm a little bit puzzled.
>> > But the inline function does not "modify memory in an unpredictable
>> > fashion", we just access it.
>> >
>> > So, my questions are:
>> > - is the inline function correct?
>> > - is the manual correct?
>>
>> That was my first take on the problem which was why I submitted the
>> patch. However, Richard's suggestion of adding a "memory" clobber
>> does indeed fix the problem (both with your original __asm__ and my
>> distilled test case).
>>
>> If rth's interpretation is right, the manual needs to be corrected.
>> If the manual is right, someone should consider applying my patch.
>> In the worst case my patch only disables "store motion" across __asm__
>> statements, rather than disabling them entirely.
>>
>>
>> As the SPEC2000 guy :>, could you check how much store motion actually
>> effects performance? Seems silly to argue over a possibly unmeasurable
>> optimization.
>
> Um, right now?
> It won't make a measurable difference, since it'll never think stores
> are okay when they are.
> It also won't hoist anything loop already doesn't handle.
Here're the requested;-) numbers for some SPEC benchmarks with -O3
-march=athlon-xp:
with store motion:
Success 164.gzip ratio=629.90, runtime=222.257335
Success 164.gzip ratio=630.69, runtime=221.978712
Success 164.gzip ratio=630.95, runtime=221.888577
Success 175.vpr ratio=322.27, runtime=434.413673
Success 175.vpr ratio=322.41, runtime=434.234616
Success 175.vpr ratio=322.22, runtime=434.484413
without store motion:
Success 164.gzip ratio=630.61, runtime=222.008486
Success 164.gzip ratio=630.86, runtime=221.919070
Success 164.gzip ratio=630.82, runtime=221.932230
Success 175.vpr ratio=322.91, runtime=433.553449
Success 175.vpr ratio=322.38, runtime=434.271049
Success 175.vpr ratio=322.84, runtime=433.654110
So no real difference for these two tests. I'll do a full spec run
tomorrow on another machine.
[...]
> Change the value of the store_ops_ok test such that store motion does
> something sometimes, and you'll start breaking a few tests on some
> platforms.
> Enabling it is just a waste of time anyway right now.
> It does nothing loop doesn't do, and what it does do, it doesn't do
> right.
>> The best person to ask to clarify the situation is Dan Berlin. Dan,
>> do you still believe that store-motion is broken? Can you provide a
>> testcase to substantiate your claims?
>
> I haven't tried in months, since nothing in store motion has changed.
> I have a patch to improve/fix most of store motion, but it still failed
> bootstrap java on x86 due to a single mismoved store because of aliasing
> bugs at the time (it worked fine and passed make check on ppc and
> sparc).
> Maybe it works now that aliasing has changed significantly.
Send it to the list and I - and probably others - will give it again
some testing and hopefully others will help fixing that aliasing bug
if it still exists,
Thanks,
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj