Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Pandu Poluan]

On Nov 29, 2011 2:02 AM, "Florian Philipp" <lists@×××××××××××.net> wrote:
>
> Am 28.11.2011 18:56, schrieb Michael Mol:
> > On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pandu@××××××.info>
wrote:
> >> On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@×××××.com> wrote:
> >>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@××××××.info>
wrote:
> >>>> Won't file a bug report, though. I have a feeling that my bug report
re:
> >>>> emerge failure will be marked WONTFIX thanks to the 'ricer special'
> >>>> CFLAGS
> >>>
> >>> The CFLAGS you showed me weren't any more ricer than "-O2
> >>> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
> >>>
> >>> They wouldn't have a leg to stand on...
> >>>
> >>
> >> Mine is:
> >>
> >> CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
> >> -floop-strip-mine -floop-block -funsafe-math-optimizations
> >> -fexcess-precision=fast"
> >>
> >> If you tell me that's not a ricer's CFLAGS, then you've just made me a
very
> >> happy cat :-)
> >
> > No, you've got some ugly flags in there. -fexcess-precision and
> > -funsafe-math-optimizations, in particular. (I must have been talking
> > to someone else last week; sorry, I'm terrible with names.)
> >
>
> I doubt -fexcess-precision=fast does anything at all. Pandu uses an
> AMD64 system, right? Then you have -mfpmath=sse set per default and SSE
> does not have excess precision issues (that's just for the old x87 FPU).

I use Intel boxes, unfortunately.

> Even if you used that, is redundant because of your other flags. To
> quote `man gcc`:
> "-fexcess-precision=standard is not implemented for languages other than
> C, and has no effect if -funsafe-math-optimizations or -ffast-math is
> specified." <-- Therefore you always have ..=fast anyway.
>
> -funsafe-math-optimizations is really terrible. Either you us floating
> point arithmetic, then you have to rely on it because it is hard enough
> already to gain necessary precision with it, or you don't, then you
> don't need that flag because it doesn't improve performance.
>

Aah, so it's FP only? Okay, one less flag to use, then.

> > -fomit-frame-pointer shouldn't cause any headaches unless you're
> > feeding a gdb stack trace, and you're not adding any debugging data,
> > so your stack traces would be pretty useless, anyway.
> >
>
> If you are on an AMD64 system, this flag is implied because it doesn't
> affect stack traces on x86_64 anymore.
>
> > I don't know about -floop-interchange, -floop-strip-mine or
> > -floop-block. I recognize at least one of them from the discussion of
> > graphite the other day.
> >
>
> These definitely need graphite to have any effect. Then they should be
> reasonably safe (as far as anything relying on experimental compiler
> frameworks can be considered safe).
>

Well, upstream says that graphite in gcc-4.5.3 is stable and production
ready, but the polyhedra analysis slows down compilation significantly. In
addition, one can easily get caught in dependency hell if the ppl package
gets an ABI upgrade.

It's kind of I_KNOW_WHAT_I_AM_DOING flag in /etc/make.conf :-)

That said, I drew the line at -floop-parallelize-all, because after
consulting with some people familiar with that flag, not only will that
flag give just a marginal improvement, but some code apparently got worse
with that flag enabled.

Rgds,