Hi!
On Fri, Dec 13, 2019 at 05:25:41PM +0100, Stefan Franke wrote:
> I suggest this patch to allow architectures do substitute cc0_rtx with a
> generated cc register.
>
> Why? If you are using a cc register plus your architecture as many
> instructions which may clobber that cc register, some passes (e.g. gcse)
> will reorder the insns. This can lead to the situation that an insn is
> moved between a compare and it' consuming jump insn. Which yields
> invalid code. (Note that at these stages clobbers are not yet tracked as
> CLOBBER insns).
Then that port has a bug. In the m68k port, there are no separate compare
and jump insns ever, but for most ports those won't yet exist during gcse.
This is not unique to cc0 conversions: every port has a similar problem
with all FIXED_REGISTERS.
> --- a/gcc/jump.c
> +++ b/gcc/jump.c
> @@ -1028,7 +1028,7 @@ sets_cc0_p (const_rtx x)
> if (INSN_P (x))
> x = PATTERN (x);
>
> - if (GET_CODE (x) == SET && SET_DEST (x) == cc0_rtx)
> + if (GET_CODE (x) == SET && rtx_equal_p(SET_DEST (x), cc0_rtx))
> return 1;
@findex cc0_rtx
There is only one expression object of code @code{cc0}; it is the
value of the variable @code{cc0_rtx}. Any attempt to create an
expression of code @code{cc0} will return @code{cc0_rtx}.
There is a lot of code that depends on this property, you cannot break
it without fixing everything.
Segher
