On 07/08/2015 09:03 AM, Renlin Li wrote:
Hi all,
In simplify_const_relational_operation function, there are cases a const
rtx
will be returned.
Three cases are considered in this function:
1, comparisons with upper and lower bounds.
2, Integer comparisons with zero.
3, comparison of ABS with zero.
It's fine to to the optimization if the operands have no side-effects.
For example, I am currently fixing a code generation bug for armv7-a
bigendian.
It turns out that, the following rtx is simplified into a const, and the
side-effect with it is ignored.
(ltu:SI (lshiftrt:SI (subreg:SI (mem/c:HI (post_modify:SI (reg/f:SI 156)
(plus:SI (reg/f:SI 156)
(const_int 20 [0x14]))) [5 g+4 S2 A32]) 0)
(const_int 1 [0x1]))
(const_int -1 [0xffffffffffffffff]))
------------>>>>>>>>>>>>>>>>>>
(const_int 1 [0x1])
This particular case falls into category 1 mentioned above. -1, when
regarded
as unsigned integer, is the largest unsigned integer. So the result is
always
a const_true_rtx in this case. However, the first operand of the comparison
has POST_MODIFY side-effect.
In this case, the simplifications should be checked against side-effect.
x86_64 bootstrapping is Okay and arm-none-eabi regression test runs
without any new issues.
Okay to commit and backport to branch 5?
Regards,
Renlin Li
gcc/ChangeLog:
2015-07-08 Renlin Li <renlin...@arm.com>
PR rtl/66556
* simplify-rtx.c (simplify_const_relational_operation): Add
side_effects_p check.
gcc/testsuite/ChangeLog:
2015-07-08 Renlin Li <renlin...@arm.com>
PR rtl/66556
* gcc.c-torture/execute/pr66556.c: New.
OK.
It may be worth looking at the .optimized dump for the new test and see
if there's something we can/should be optimizing better before we start
generating RTL. That can obviously be a follow-up.
jeff
