[PATCH] 19705 - -fno-branch-count-reg doesn't prevent decrement and branch instructions on a count register

[PATCH] 19705 - -fno-branch-count-reg doesn't prevent decrement and branch instructions on a count register

[Martin Sebor]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

The more than decennnial rtl-optimization/19705 - -fno-branch-count-reg
doesn't prevent decrement and branch instructions on a count register
points out that the documentation of the option leads one to expect
that it prevents the decrement and branch instruction from appearing
in the instruction stream.  This isn't the case  The option prevents
a dedicated pass from running that introduces such instructions, but
it doesn't prevent other passes from introducing it.  The attached
updates the documentation to clarify this.

Martin

[-- Attachment #2: gcc-19705.patch --]
[-- Type: text/x-patch, Size: 1561 bytes --]

PR rtl-optimization/19705 - -fno-branch-count-reg doesn't prevent decrement
	and branch instructions on a count register

gcc/ChangeLog:
2016-02-11  Martin Sebor  <msebor@redhat.com>

	PR rtl-optimization/19705
	* doc/invoke.texi (Options That Control Optimization): Clarify
	-fno-branch-count-reg.

Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi	(revision 233355)
+++ gcc/doc/invoke.texi	(working copy)
@@ -6513,11 +6513,14 @@ life-range analysis.  This option is eff
 
 @item -fno-branch-count-reg
 @opindex fno-branch-count-reg
-Do not use ``decrement and branch'' instructions on a count register,
-but instead generate a sequence of instructions that decrement a
-register, compare it against zero, then branch based upon the result.
-This option is only meaningful on architectures that support such
-instructions, which include x86, PowerPC, IA-64 and S/390.
+Avoid running a pass scanning for opportunities to use ``decrement and
+branch'' instructions on a count register instead of generating sequences
+of instructions that decrement a register, compare it against zero, and
+then branch based upon the result.  This option is only meaningful on
+architectures that support such instructions, which include x86, PowerPC,
+IA-64 and S/390.  Note that the @option{-fno-branch-count-reg} option
+doesn't remove the decrement and branch instructions from the generated
+instruction stream introduced by other optimization passes.
 
 Enabled by default at @option{-O1} and higher.
 

Re: [PATCH] 19705 - -fno-branch-count-reg doesn't prevent decrement and branch instructions on a count register

[Martin Sebor]

Ping:

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00809.html

On 02/11/2016 02:58 PM, Martin Sebor wrote:
> The more than decennnial rtl-optimization/19705 - -fno-branch-count-reg
> doesn't prevent decrement and branch instructions on a count register
> points out that the documentation of the option leads one to expect
> that it prevents the decrement and branch instruction from appearing
> in the instruction stream.  This isn't the case  The option prevents
> a dedicated pass from running that introduces such instructions, but
> it doesn't prevent other passes from introducing it.  The attached
> updates the documentation to clarify this.
>
> Martin

Re: [PATCH] 19705 - -fno-branch-count-reg doesn't prevent decrement and branch instructions on a count register

[Jeff Law]

On 02/18/2016 08:39 PM, Martin Sebor wrote:
> Ping:
>
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00809.html
>
> On 02/11/2016 02:58 PM, Martin Sebor wrote:
>> The more than decennnial rtl-optimization/19705 - -fno-branch-count-reg
>> doesn't prevent decrement and branch instructions on a count register
>> points out that the documentation of the option leads one to expect
>> that it prevents the decrement and branch instruction from appearing
>> in the instruction stream.  This isn't the case  The option prevents
>> a dedicated pass from running that introduces such instructions, but
>> it doesn't prevent other passes from introducing it.  The attached
>> updates the documentation to clarify this
I'm not even sure why we have this option to begin with.  One could 
easily argue that it's mis-named or should just go away.

In the mean time, your patch at least clarifies what it really does, so 
it's fine for the trunk.

jeff