User account creation filtered due to spam.
Hmm, this is werid, why cannot I turn off doloop optimization with the -fno-branch-count-reg when I
also turn off ivopts? I should be able to when I want to look at the interaction between those two
int foo (int x)
int i= x;
x *= 2;
} while (--i);
Compile with -O2 -fno-branch-count-reg -fno-ivopts and see there still is a bdnz in there.
but compile with -O2 -fno-branch-count-reg and you don't get the bdnz.
Werid it is combine which is doing it. Hmm and this is not a regression.
Either the documention needs updating or the targets need to turn off these patterns when -fno-
branch-count-reg is supplied.
Confirmed, the documention just needs to changed as that -fno-branch-count-reg only turns off the
extra analysis and that you can still get code using the branch counter even when using this option.
Or make the doloop insn patterns conditional on flag_branch_on_count_reg?
(In reply to comment #3)
> Or make the doloop insn patterns conditional on flag_branch_on_count_reg?
I had this discussion with David Edelsohn and he said that was not the correct approach.
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.)
Documentation patch posted for review:
Date: Mon Mar 7 17:10:12 2016
New Revision: 234039
PR rtl-optimization/19705 - -fno-branch-count-reg doesn't prevent decrement
and branch instructions on a count register
2016-03-07 Martin Sebor <firstname.lastname@example.org>
* doc/invoke.texi (Options That Control Optimization): Clarify
Documentation clarified in r234039.