Re: [DOC Patch] Explicit Register Variables

[Jeff Law <law at redhat dot com>]

On 06/30/14 17:10, David Wohlferd wrote:
> > > - Describing Local Register Variables as "sometimes convenient for use
> > > with the extended asm feature" misses the point that this is in fact the
> > > ONLY supported use for Local Register Variables.
> > What makes you believe that this feature is only useful for extended
> > asms?  My recollection is that for the last 20+ years this feature has
> > served effectively as a pre-allocation of certain function scoped
> > objects into predetermined registers.
>
> That's great feedback.  The existing docs don't even mention that use.
> If you have a link (or if you can put together a few sentences)
> describing how you could use it for this, I'll add it and re-work the
> text.  And if you can think of any other common uses, I'd be glad to add
> them too.
I think that's fundamentally what the feature was meant to be used for; 
the fact that it wasn't ever well documented is unfortunate.

Then again, there were many aspects of GCC's early documentation that 
were poor and misguided.

I'm not really sure what I'd add -- the docs already largely describe 
the net effect.  Maybe just "This extension, in effect, pre-assigns a 
target register to a particular variable.  This option does not 
guarantee that GCC generates code that has ..."

> > Not sure I really agree with this either.  There's nothing inherently
> > wrong with someone trying to use a local register variable to try and
> > optimize code for example.
>
> Umm.  Well.  Hmm.  You haven't said this was a good idea or even that it
> would work, so I guess the statement that there's nothing "inherently
> wrong" with it is true.
Right.  I personally wouldn't take that approach, but I'm far more 
concerned about portable code and trust the register allocators to make 
generally good decisions.  Could someone possibly do a better job than 
the register allocator by using local register variables?  Most likely, 
yes.  And for some subset of developers that may be worth the 
maintenance pain.



 However, by explicitly stating it is not
> supported, we would be making it clear that when the next release uses
> registers in a slightly different way that wipes out all their
> "improvements," we can say "we told you that wasn't a supported use of
> this feature."
>
> However, I'm prepared to remove or rework this statement if you feel
> strongly.
Well, the whole point behind the feature is to allow someone to do 
precisely what you're saying isn't supported.  So, yea, I feel pretty 
strongly that such language is not appropriate.


> I *almost* sent this as an RFD to the gcc list.  But it being such an
> obscure area, I wasn't really expecting much response (see
> https://gcc.gnu.org/ml/gcc-help/2014-04/msg00124.html for example). The
> items listed in my "problem description" were only highlights. As you
> have no doubt noticed, nearly all the text on these 2 pages got
> modified.  If you have feedback on any of the rest of the text, I'd love
> to hear it.
You sent it as we were approaching the 4.9 release; speaking strictly 
for myself, my focus is very much on fixing code generation, ICE and 
related regressions at that point.  Everything else gets pushed down the 
queue.

As far as further improvements to those docs; I'm happy to work with you 
on improving it -- but I've got a lot on my plate and really can't 
justify reviewing docs for some of the less important extensions like 
this, except in a reviewing role.

jeff