This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

question about constant-folding compares...



I've got a 2.8.1 based port of GCC to the Analog Devices 2106x DSP
that has behavior that's got me scratching my head..

    (insn 66 63 301 (set (reg/v:SI 130)
	    (const_int 0)) 37 {dagsub-1} (nil)
	(expr_list:REG_EQUAL (const_int 0)
	    (nil)))


    (insn 301 66 302 (set (cc0)
	    (compare (reg/v:SI 130)
		(reg/v:SI 126))) 186 {cmpsi} (nil)
	(nil))

The above rtl is generated by the code that expands  something like:

	for(i=0; i<lim; i++)

for the loop pretest.

This RTL makes it all the way into combine, where the compiler makes a
valiant effort to generate

	(set (cc0) (reg 126))

and fix up the following conditional branch to reverse the sense of the test appropriately

But because combine tried to construct a

	(parallel [(set (cc0) (reg:SI 126))
		   (set (reg 130) (const_int 0))])

and there's no DEFINE_INSN for this pattern (and there can't be because reload
can't handle an instruction that SETS a pseudo and sets CC0).

So try_combine fails and undoes all the good work.

This results in really bad code when the (reg 130) ends up in a register that's not
allowed in a compare!

Is this something that the 2.95 GCSE pass handles?

Anything short of upgrading my port to 2.95 that would help this?

-- Al Lehotsky

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]