Re: [PATCH][libstdc++-v3 parallel mode] Make settings getter return non-const object

[Benjamin Kosnik <bkoz at redhat dot com>]

Hey Johannes. Sorry about the delay.

> This patch makes the getter method for the parallel mode settings 
> structure return a non-const object, so it can be directly modified, 
> which is much more convenient for the library user.

I see where you are coming from, if one is trying to use the get()
function to construct a modified _Settings object.

Like so:

using namespace __gnu_parallel;
_Settings s = const_cast<_Settings>(_Settings::get());
s.something = somenewthing;
_Settings::set(s);

This is what you are trying to avoid, hmmm?

My thought was that this would be used more like:

_Settings s;
s.something = somenewthing;
_Settings::set(s);

See the updated documentation that was just checked in as part of
libstdc++/35256.

So, the question is, does this make sense? 

Anyway.

I do believe that there are solid codegen reasons for having the get()
member return a const object, implying all the object members are const.
By doing it this way, all the tuning information is constant at the
site of use... this should allow the optimizers to elide the jump from
get() and propagate the const configuration data. So, just like a
macro! (?)

Kind of hand-wavy at this point, I admit. 

If the long-term goal is to force some of the parallelization
heuristics into the compiler proper, (what I'm assuming), then doesn't
this stuff have to be const at some point?

That may depend on IPA for C++ that is still not quite there yet. So,
perhaps I'm getting ahead of myself...

> AFAIK this does not change library binary compatibility, does it?

Nope. It only changes the const qualification of the return
type, which is not part of the mangled name. So, it's definitely safe
to do this.

-benjamin

ps. Check out the gomp-3_0-branch. Some interesting
performance improvements from
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00930.html and later...