Proposed doc update for Explicit Reg Vars 3/3

[Jeff Law]

On 10/20/2015 10:35 PM, David Wohlferd wrote:
>
>  > 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...
Seems reasonable.

>
>  > 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?
I don't think you missed anything.   We're not making behavioural 
changes in your patch, but we are codifying in the documentation that 
using explicitly register variables to guide register allocation isn't 
strictly supported and more generally tightening what's considered 
supported for local explicit register variables.

People look at our documentation, particularly for extensions, as a 
contract.  History has consistently shown that when we change the 
contract, there will be blow-back.

And it's not an unreasoanble stance for the end-users to take.  They 
simply want to know what they can rely upon.  For the standardized parts 
of the language, they obviously can refer back to the standard.  For 
extensions, they have to refer to the GCC manual.

It's also the case that other compilers such as ICC and LLVM refer back 
to GCC's extension documentation when they write their compatibility codes.

One could possibly argue that there should be a disclaimer for all the 
extensions to ensure there's "wiggle room" to adjust the contract when 
the need arises.

>
> 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?
Your call -- folks will be switching from a development to a bugfixing 
mindset shortly as the gcc6 development window closes.  Hopefully 
someone will take a look at this particular issue at that time.

jeff