Proposed doc update for Explicit Reg Vars 3/3

David Wohlferd dw@LimeGreenSocks.com
Wed Oct 21 04:35:00 GMT 2015


I'm trying to sum up what was discussed here.  What I'm hearing is 
(quoting Jeff):

 > the technical reality is I can't see a use outside the extended asm.

Andrew has discussed some other uses, but as Jeff observed:

 > Given the way the optimizers and register allocation work,
 > I don't think we can make guarantees around [Andrew's] use
 > of the feature.  It happens to still work and may work
 > forever, but I'm not going to set it in stone.

If the only usage we are prepared to "set in stone" is extended asm, 
then it follows that that is the only supported usage.  Areas of 
"non-guaranteed behavior" are things the docs should actively discourage 
people from using.

Given this, I'm going to go ahead and re-work the local register 
variables page (probably tomorrow) stating extended asm is the only 
supported usage.  Although I also think it's important to mention 
Andrew's point.  If someone sees it in code somewhere, at least the docs 
will give them some idea what is going on.

Stop me if I've got this all wrong...

 > dealing with any blow-back we get along the way

Since no one is proposing any code changes here, it's not like people's 
programs are going to stop working tomorrow.  It's possible that some 
future code change to the Local Register Variables feature (perhaps 
provoked by this doc change) will break something.  But if the broken 
use case is deemed valid, it's the *code* change that should get the 
blow-back, not the doc change.  Hopefully when that happens, the new use 
case will then be added to the Local Register Variables docs.  Probably 
as a chunky block at the end of the page, but still...

Or did I miss your point?

Nobody has commented on 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64951 (register variable 
with template function).  While I'm updating the page, is this a 
limitation of Local Register Variables that should be doc'ed?

dw



More information about the Gcc mailing list