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]

Re: Reload pass clobbers cc0


At 2:29 AM +0100 8/17/00, Kenn Humborg wrote:
>On Wed, Aug 16, 2000 at 04:57:10PM -0400, Alan Lehotsky wrote:
>...
>  But on a machine with a lot
>  > of addressing modes like the VAX, it's going to get ugly really quick
>
>Thanks.  That's sorted it out.  And actually it's not too
>bad.


	Ah, I forgot both how regular the vax is with respect to
	source and destination operands and how orthogonal it is.
	Which should be embarassing, as I did the first native interpreter
	on the VAX (a toy lisp system that ran in under 4kb on a vax 
simulator),
	and the first compiler (Bliss32).

	The port I did for a DSP chip was 1-1/2 address architecture
	with very strict limitations on what registers could be paired
	with what memory addressing modes - I had 12-15 different
	cases (also because materializing constants like zero and one
	was special....) for the MOVSICC pattern.

>   The original sgeu looked like this:
>...
>
>The modified one look like:
>
>    (define_insn "sgeu"
>      [(set (match_operand:SI 0 "general_operand" "=ro,<>")
>            (geu (cc0) (const_int 0)))]
>      ""
>      "@
>       movl $1,%0\;sbwc $0,%0
>       bgequ 1f\;clrl %0\;brb 2f\;1f: movl $1, %0\;2f:")
>
>I think this should catch everything.

	You might better write that as...

  	bgequ %=f\;clrl %0\;brb %=b\;%=f: movl $1, %0\;%=b:")


>
>Now, it would be nice if these insns could be flagged as
>'never reload' or 'trigger internal compiler error if
>reloaded'.

	Well, you did get the "trigger internal compiler error",
	didn't you :-)

	The "never reload" would be VERY difficult to guarantee,
	because of the way that register allocation occurs.

>I'm just left wondering how far back this problem goes, and
>if anyone's ever spotted it.  The current offical vax.md
>doesn't define a udivsi3 insn or expand, but GCC still
>generates incorrect code when optimizing


	Yeah, I've been doing compilers since 1975 and I'm amazed
	at how long certain bugs can survive (software cockroaches,
	I guess....) and how others like thinking you can use
	right shifts for a divide-by-powers-of-two on a signed
	dividend keep spontaneously regenerating..

	Regards,
	-- Al
-- 
------------------------------------------------------------------------

		    Quality Software Management
		http://www.tiac.net/users/qsmgmt
			apl@alum.mit.edu
			(978)287-0435 Voice
			(978)808-6836 Cell
			(978)287-0436 Fax

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation

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