This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/77499] [7 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range
- From: "avieira at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 07 Sep 2016 08:48:31 +0000
- Subject: [Bug rtl-optimization/77499] [7 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range
- Auto-submitted: auto-generated
- References: <bug-77499-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #6 from avieira at gcc dot gnu.org ---
> so we are talking about the uxthne insn (I don't know arm / thumb very well).
Yes, the uxthne is the "zero_extend" that is otherwise optimized away if you
turn off code-hoisting.
This is because the way the code gets transformed leads to:
r112:SI=r112:SI 0>>0x1, this is the combination of instructions 12 and 13 in my
example earlier. r112 is also the first operand of the xor instruction and
because of the way combine does its "nonzero bit analysis" it always looks at
the last set value for each pseudo. For r112 here, thats an infinite loop and
so it will not be able to recognize that r112 originated from r0, thus loosing
the information that it is at most an unsigned short. Leading to the decision
not to get rid of the zero_extend.
I'll have a look at if-convert.