Re: Does zero_extend (const_int) *ever* have a valid meaning

[Richard Earnshaw <rearnsha at arm dot com>]

> > On Fri, Sep 20, 2002 at 05:37:57PM +0100, Richard Earnshaw wrote:
> > > So, is cse correct in trying to make this substitution?
> > 
> > No, not without other simplifications.  Zero_extend requires
> > an inner mode, which const_int doesn't have.
> 
> That was my understanding.  So are there already places in the compiler 
> that know how to deal with this that I can use as the basis to fix this 
> case?
> 
> R.
> 
> 


OK, I understand what the failure mode is now.

We start with

(expr_list:REG_EQUAL (ashift:DI (zero_extend:DI (subreg:SI (reg/v:DI 
67) 0)) (const_int 4 [0x4]))

Where cse knows that (reg/v:DI 67) is equivalent to (const_int 0)

Now fold_rtx recurses down to the point where it is simplifying the 
zero_extend.  It finds out that the subreg is equivalent to a constant and 
substitutes this value *directly* into the expression.  It then correctly 
simplifies zero_extend:DI (const_int 0) knowing that the mode of the 
const_int is SImode, and returns (const_int 0) to its caller.

Its caller was a fold_rtx operating on the ashift expression.  This now 
starts to substitute into its own operand the replacement for the 
zero_extend.  But before doing so it calculates the cost of the *old* 
expression which is the invalid zero_extend -- this is where the abort 
occurs.

So the next question is, should rtx_cost be required to accept this 
invalid RTL, or should we find a way to prevent the substitution into the 
original expression?