Re: missing explanation of Stage 4 in GCC Development Plan document
On Mon, Oct 19, 2015 at 3:41 AM, Gerald Pfeifer wrote: > fOn Tue, 28 Apr 2015, Richard Biener wrote: Stage 2 has been missing for 7 years now, Stages 3 and 4 seem to blur together, the "regression only" rule is more like "non-invasive fixes only" (likewise for the support branches). >>> Don't stage3 and stage4 differ in that substantial changes are still >>> allowed for backends in stage3? >> stage3 is for _general_ bugfixing while stage4 is for _regression_ bugfixing. > > I am wondering, do we want to keep this "forever", or adjust to > the fact that stage 2 has been non-existent for a while? > > We may not want to redefine stage 3 to 2 and stage 4 to 3, but could > use stage A, B, and C? (Or in fact alpha, beta, and RC phases which > is what this essentially has become?) I think we'd want to transition to more descriptive stage names. Like "Development Stage" (stage1), "Stabilization Stage" (stage3) and "Release Stage" (stage4). Note that Stage 4 is equal to the state release branches are in (but we didn't yet branch for the release), thus "Release Branch Stage" would be even better but also possibly confusing (there isn't a branch). Richard. > > Gerald
Re: Proposed doc update for Explicit Reg Vars 1/3
On 10/12/2015 04:06 PM, David Wohlferd wrote: Note that there is nothing actually "wrong" with the existing text. It does not provide inaccurate information or miss key details. The problem is that (from a compiler user's point of view) the text is hard to follow. It reads as though people just have just dropped in new text as it occurs to them, without ever going back to put things in context, add formatting, etc. That's probably exactly how it grew over time. As issues were discovered, doc text was added, but nobody ever stepped back and look at the section as a whole. The current menu page has a couple of flaws: 1) It tries to condense the entire contents of the other 2 pages into a single paragraph each. This loses a lot of detail and nuance, as well as introducing unnecessary duplication of information with the subpages. Probably an attempt to help guide which of the two pages one ought to look at. 2) What the heck is a "reg var"? Why can't we just call this a "register variable"? No reason. Instead of trying to fix/clarify/update the duplicated information, this patch removes it, then provides enough information to differentiate the two types of register variables, and finally directs people to the appropriate subpages which already contain all the information from this page (and more). It also changes the section names (and refs within the docs) to avoid the unnecessary abbreviations. As part of this, it also uses @anchor to ensure that any external links to the old names will still resolve correctly. Is this the standard? Or do we just let them fail? For people who find the HTML easier to review: Looks good to me. IIRC, you didn't have commit access, so I'll go ahead and commit this for you. Thanks! jeff
Re: Proposed doc update for Explicit Reg Vars 1/3
On Mon, Oct 12, 2015 at 03:06:19PM -0700, David Wohlferd wrote: > But now it has annoyed someone who is willing to work on it. And thanks for that :-) > The current menu page has a couple of flaws: > > 1) It tries to condense the entire contents of the other 2 pages into a > single paragraph each. This loses a lot of detail and nuance, as well > as introducing unnecessary duplication of information with the subpages. It provides an introduction, which is quite helpful in this case. Without some blurb the two-entry menu looks silly too. Can you move the intro to the separate pages instead of losing it altogether? > 2) What the heck is a "reg var"? Why can't we just call this a > "register variable"? It is shorter and as such makes the menus (both in the body text and in the navigation) look nicer. But there are many other long names, of course. Abot the patches themselves... Hard to review again, sigh... Two spaces after a full stop, one after a comma. Segher
Re: Proposed doc update for Explicit Reg Vars 2/3
On Mon, Oct 12, 2015 at 04:07:48PM -0700, David Wohlferd wrote: > Index: extend.texi > === > --- extend.texi (revision 228690) > +++ extend.texi (working copy) > @@ -8506,7 +8506,8 @@ > @cindex global register variables > @cindex registers, global variables in > > -You can define a global register variable in GNU C like this: > +You can define a global register variable and associate it with a specified > register Line too long. I know quite a bit of doc does that, but that's no excuse :-) > +Registers can be a limited resource on some systems and allowing the They are a limited resource on almost all systems. "Scarce resource"? > +After defining a global register variable, for the duration of > +the current compilation: It's probably better to say "for the current compilation unit"? There now is LTO and whatnot. > +All global register variable declarations must precede all function > +definitions. If such a declaration appears after function definitions, > +the declaration would be too late to prevent the register from being used > +for other purposes in the preceding functions. This isn't true anymore, not even with -fno-toplevel-reorder or -O0. > +When selecting a register, choose one that is normally saved and > +restored by function calls on your machine. This ensures that code > +which is unaware of this reservation (such as library routines) will > +restore it before returning. The compiler also warns, possibly for the unlikely case that the user has not read the documentation. Thanks, Segher
Re: Proposed doc update for Explicit Reg Vars 3/3
On Mon, Oct 12, 2015 at 04:09:34PM -0700, David Wohlferd wrote:
> I was hoping to modify the text to say that local register variables can
> "only" be used to call Extended asm. This would greatly simplify this
> section.
But it is not true: they can be used anywhere any variable can be used.
Only in asm operands is it guaranteed that they end up in certain regs
though.
> -This option does not guarantee that GCC generates code that has
> -this variable in the register you specify at all times. You may not
> -code an explicit reference to this register in the assembler
> -instruction template part of an @code{asm} statement and assume it
> -always refers to this variable.
> -However, using the variable as an input or output operand to the @code{asm}
> -guarantees that the specified register is used for that operand.
> -@xref{Extended Asm}, for more information.
... as this correctly said.
> +Defining a register variable does not reserve the register; it
> +remains available for other uses in places where flow control determines
> +the variable's value is not live. For this reason, the following uses
This is misleading -- people will try to keep the variable "live" so it
stays in the wanted reg. Which is not something guaranteed to work either.
Segher
Re: Proposed doc update for Explicit Reg Vars 2/3
On 10/12/2015 05:07 PM, David Wohlferd wrote: - There are unsourced, unsubstantiated reports that on some platforms, certain things might or might not work. Back when this was written (circa 1996), this would have been considered helpful information -- having a system routine clobber a register unexpectedly actually did happen. Been there, done the debugging, want to forget. Since then, system software as gotten better. And the details of what may have failed on some version of SunOS/Solaris or on the 3b1 just aren't that important anymore. So I don't mind losing that information. - Eventually the compiler may work differently than it does now. That is helpful. It's a way signaling that things may change and that depending on the precise syntax and semantics may be unwise. From time to time, particularly with GCC extensions, it has been necessary to declare certain usage as invalid or to change the implementation is significantly visible ways. We never like doing that, but it is sometimes unavoidable. As a general rule, the more an extension exposes how GCC works internally, the more likely it has been to need significant changes over time. (asms being the easiest example to cite). So please consider keeping something which signals the semantics might change. As for the review, perhaps reading the html is easier than reading the patch :-0 I think reviewing the HTML is easier. Thanks for providing a link. So for the example, "a5" is a particularly bad choice these days on the m68k as it's the PIC register. It may be advisable to just use r for some value of N and try to be processor agnostic here. Segher's comments are valuable as well. I think if you integrate his and mine the result ought to be ready to commit. jeff
Re: Proposed doc update for Explicit Reg Vars 2/3
On 10/19/2015 03:42 PM, Segher Boessenkool wrote: +After defining a global register variable, for the duration of +the current compilation: It's probably better to say "for the current compilation unit"? There now is LTO and whatnot. Which raises the question, what happens for LTO? Do we stream out enough information to know about global register variables and if we do, then its use as a global register variable implicitly covers anything that's visible at LTO time, right? +All global register variable declarations must precede all function +definitions. If such a declaration appears after function definitions, +the declaration would be too late to prevent the register from being used +for other purposes in the preceding functions. This isn't true anymore, not even with -fno-toplevel-reorder or -O0. I've asked David to verify this. However, if you have, then he doesn't need to re-confirm. Jeff
Re: Proposed doc update for Explicit Reg Vars 3/3
On 10/12/2015 05:09 PM, David Wohlferd wrote: Patch 3/3 is the update for the Local Register Variables page (attached). This patch starts with a question. Looking at bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64951 (register variable with template function) is this a bug that will be fixed? Or a limitation that should be doc'ed? Both the current docs and the patch ignore this bug. As with patch #2, this is primarily about reformatting/reorganizing. Although it also adds the limitation from asm labels re statics. I was hoping to modify the text to say that local register variables can "only" be used to call Extended asm. This would greatly simplify this section. But there has been pushback on this (despite the fact that no one has really suggested any other reasonable use). So I have softened this, and listed things from the existing docs that are explicitly not supported. For people who find the HTML easier to review: Here's the current text: https://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html And here's the new: http://limegreensocks.com/gcc/Local-Register-Variables.html dw Like with the global register variables, please consider going processor agnostic here and using r for some value of N rather than using severely dated m68k examples. WRT your hope to limit this to only uses in extended asms. That'd be nice, but that's never been an explicit limitation. I would strongly hesitate to add that limitation at this point in time. Jeff
Re: Proposed doc update for Explicit Reg Vars 3/3
On 10/19/2015 03:55 PM, Segher Boessenkool wrote:
On Mon, Oct 12, 2015 at 04:09:34PM -0700, David Wohlferd wrote:
I was hoping to modify the text to say that local register variables can
"only" be used to call Extended asm. This would greatly simplify this
section.
But it is not true: they can be used anywhere any variable can be used.
Only in asm operands is it guaranteed that they end up in certain regs
though.
-This option does not guarantee that GCC generates code that has
-this variable in the register you specify at all times. You may not
-code an explicit reference to this register in the assembler
-instruction template part of an @code{asm} statement and assume it
-always refers to this variable.
-However, using the variable as an input or output operand to the @code{asm}
-guarantees that the specified register is used for that operand.
-@xref{Extended Asm}, for more information.
... as this correctly said.
+Defining a register variable does not reserve the register; it
+remains available for other uses in places where flow control determines
+the variable's value is not live. For this reason, the following uses
This is misleading -- people will try to keep the variable "live" so it
stays in the wanted reg. Which is not something guaranteed to work either.
I think some of the confusion here is that paragraph is just hard to
parse. To some degree this is inevitable because you have to think like
a compiler junkie. Perhaps something like this.
Defining a register variable does not reserve the register. The
register remains available to hold unrelated values in places where the
variable is not live according to dataflow analysis.
jeff
