This is the mail archive of the gcc-patches@gcc.gnu.org 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: GCC 3.1 Issues


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


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