Re: [pooma-dev] GCC 3.2 on Redhat 8.0--a fair number of compiler warnings?

[Richard Guenther]

On 23 Apr 2003, George Talbot wrote:

> On Wed, 2003-04-23 at 16:50, Richard Guenther wrote:
> > On 23 Apr 2003, George Talbot wrote:
> >
> > > Hi,
> > >
> > > New POOMA II user.  Got everything to compile and link today.  The
> > > performance of this stuff is shocking.
> > >
> > > I ran a hand coded version of your 2D diffusion program on my box for
> > > 250 steps, 800x800 array.  1m34s, uniprocessor.
> > >
> > > Using a stencil, same box, uniprocessor.  25s.  WOW.
> > >
> > > Using -shmem -np 2 to distribute the shared array version on both of my
> > > processors on my box.  12s.  Truly amazing.  I think this may be a
> > > dramatically useful tool.
> >
> > You will find gcc-3.3 even more useful, combined with careful inline
> > parameter tuning!
>
> Really?  What enhancements make POOMA speedier?  The DFA scheduler?
> Type-based alias analysis for aggregates?  All of the above?  ;^)

Mostly the DFA scheduler and the possibility to specify --param
min-inline-insns=300 ;) The rest surely helps, too.

> > > The only thing that irks me a bit is that there are a fair number of
> > > compiler warnings, which I will append, along with the source I used, to
> > > this e-mail.  Is this normal?  Swimming in a sea of warnings from the
> > > POOMA headers, I might miss some on my own code...
> >
> > Without -Wall I dont see warnings from the POOMA headers with g++/icpc,
> > but you are right, theres something to clean up. But as time is always
> > short, fixing warnings that dont annoy me is not very high on my priority
> > list. But I'm sure we're accepting patches to correct them (maybe...).
>
> So I'm on my own, eh?  ;^)  If I come up with any good patches for
> cleaning up warnings I encounter, shall I post them to this list?  Are
> there any preferred formats?

I'd use unified diffs. But be warned that there may be license/copyright
issues with accepting your work - Jeffrey may comment on this.

But I think its about identifying the most annoying ones that come up
again and again.

Richard.