[Bug target/65768] sub-optimimal code for constant Uses in loop

[kugan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65768

kugan at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |kugan at gcc dot gnu.org

--- Comment #1 from kugan at gcc dot gnu.org ---
Zhenqiang posted following patches in this regard.

[PATCH, cprop] Check rtx_cost when propagating constant
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01321.html

[PATCH, ARM] Keep constants in register when expanding
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00325.html


Note that, Zhenqiang's patch still will not work for 0x00ff00ff and works only
for 0xfe00ff (as used in the testcase for the above patch).

For the case of 0x00ff00ff, this constant is splt by the backend during expand
as:

(insn 52 51 53 (set (reg:SI 154)
        (const_int 255 [0xff])) const1.c:6 -1
     (nil))

(insn 53 52 54 (set (zero_extract:SI (reg:SI 154)
            (const_int 16 [0x10])
            (const_int 16 [0x10]))
        (const_int 255 [0xff])) const1.c:6 -1
     (nil))

The ZERO_EXTRACT has 255 as the src (from 0xff00ff) which (same constant 255)
is also set in the same register in the previous instruction. So, during CSE,
it
detects that they are same and using r154 when simplifying ZERO_EXTRACT with
the
constant. But in the case of, 0xfe00ff, theses two constants are different (255
and 254) hence CSE simplifies it back to  0xfe00ff. RTL loop invariant code
motion can now move it out. However, if the constant is still split and are
constructed with two instructions, it will not be able to move it out.

I believe the fix is to delay splitting. i.e., do not split for SET as well
during expand.

CSE simplifying ZERO_EXTRACT is probably not wise as well because it is doing
this without consulting the back-end cost.