Re: [Patch] Fix istream::ignore + minor things

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Fri, May 28, 2004 at 12:29:07PM +0200, Gabriel Dos Reis wrote:
> Nathan Myers <ncm-nospam@cantrip.org> writes:
> 
> [...]
> 
> | Second, compiler core people seem very sensitive to whether a feature
> | is actually used in the code they encounter (typically in bug reports)
> | before they put any time into improving their implementation of that
> | feature.  At the moment, they probably hardly ever see branch prediction 
> | attributes, because its expression isn't portable.  If we start using 
> | them heavily in our library, the compiler people will be more likely 
> | to start paying them some attention.
> 
> This is very selffulfilling.  It is not like they don't care.
> I distinctly remember that this thingy had been discussed with
> compiler people, especially with RTH (implementor).  Furthermore, Matt
> also asked and suggested (if beneficial) to start using it in the
> compiler itself.  It is not like, we just discovered it and the
> compiler people did not know about it and its uses -- you may want to
> grep the compiler source itself.

Of course.  It's a chicken-and-egg problem, or a bootstrapping problem.
Everybody wants it, but it's hard to justify putting much work into
compiler patches without presenting real user-level code that is 
improved by them.  We can provide tha user-level code.

> | Once such annotations actually
> | help, then users will start using them in their own code too, and a
> | some ISO committee might then feel obliged to make it portable.  
> 
> like computed gotos, or old lovely-regretted GGC's named return value
> syntax, for example. 
> 
> | This isn't a call to start annotating all conditionals, wholesale.
> | Practically, I think this means that for bits of code that we already
> | *know* are very commonly inlined in inner loops, we shouldn't demand 
> | complete benchmark tests on all architecures before we welcome patches 
> | to annotate those.
> 
> On the contrary I'm of the strong opinion that we should ask for data
> and carefully consider the issues. 

We are always careful.  As it is, though, any data will say "this patch
makes no difference", until after it is applied, and after the compiler 
is patched to use it.  We can then welcome reports of "that patch now 
makes a big difference".  We can then try to identify other places 
where it alsos makes a big difference, or where it ought to -- but 
(again) won't until we apply it anyway, and nag the optimizer people 
to fix it.

It's this dance.

Nathan Myers
ncm-nospam@cantrip.org