https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19705
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2006-03-05 03:12:14 |2016-1-27
CC| |msebor at gcc dot gnu.org
Summary|Cannot turn off doloop |-fno-branch-count-reg
|optimization via |doesn't prevent decrement
|-fno-branch-count-reg if |and branch instructions on
|-fno-ivopts is also |a count register
|supplied |
Known to fail| |4.9.3, 5.3.0, 6.0
--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
I spent a bit of time looking at this today (more than I should have).
Based on the comments and based on my own testing and debugging, the Summary of
this bug isn't correct: the -fno-branch-count-reg option does disable the
doloop optimization (even when -fno-ivopts). What's not correct is the
description of the effects of the option in the manual:
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.
I've adjusted the Summary to reflect that.
That said, I'm not sure what would be a meaningful update to the documentation.
Saying that the -fno-branch-count-reg option may not actually do what its name
implies it's meant to do because there's some other pass that might do the
opposite doesn't seem very helpful.
FWIW, I was curious to know what pass is responsible for inserting the bdnz
instruction. It seems that it's the combine pass and only in 32-bits. That's
the first pass where I see the ctrsi_internal1 pattern introduced for the test
case. (powerpc64 doesn't emit bdnz when -fno-branch-count-reg is used, at
least not for the test case.)
Anyway, with this background my opinion, for whatever it's worth, is that if
the purpose of the -fno-branch-count-reg option is to let users (as opposed to
GCC developers) control the kind of code that GCC emits then this seems like a
bug in the compiler that should be fixed by changing it to avoid emitting the
ctr<mode>_internal* patterns. Otherwise, if its purpose is to let GCC
developers control whether or not the doloop pass runs, then that's how the
option should be documented. (I do realize that despite what the manual
suggests these options are primarily used for debugging GCC so perhaps the
second alternative is the way to go.)
