This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [DOC Patch] Explicit Register Variables

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
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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]