Re: LOAD_EXTEND_OP crippled

[Daniel Jacobowitz <drow at false dot org>]

On Mon, Jun 14, 2004 at 04:05:15PM -0400, Daniel Jacobowitz wrote:
> Hi Roger,
> 
> I'm trying to understand your patch from:
>   http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00383.html
> 
> You wrote:
>  The bug is that simplify_comparison believes that (subreg (reg ...))
>  has undefined upper bits, but the two functions nonzero_bits and
>  num_sign_bit_copies believe (subreg (reg ...)) is extended according
>  to LOAD_EXTEND_OP.  The fix below is to tighten the extension tests
>  in these two functions to check "GET_CODE (SUBREG_REG (x)) == MEM".
> 
> I don't think that's what the code was doing.  It's not believing that it
> will be extended in some particular way, but rather that its high bits are
> not rendered undefined by a move - whatever we already knew about them. 
> This fits with the definition of WORD_REGISTER_OPERATIONS.

I think this message can just be disregarded.  I made what I figured
were completely unrelated changes to the port, and now it behaves as
I'd expect - by the time we get to this point in combine we've already
replaced the pseudo with the MEM that set it.

I have to define an explicit instruction for (set (reg) (zero_extend
(mem))), which I think is kind of a shame since LOAD_EXTEND_OP implies
that (set (reg) (mem)) does the zero_extend.  This is needed because
another part of combine will later turn (set (reg) (subreg:DI (mem:SI))
back into a zero_extend.  That's assuming that I have the problem
figured out correctly, since I still can't get the right results
produced.  But it means my objection to the patch is unfounded.

I'm going to crawl back into RTL dumps now.

-- 
Daniel Jacobowitz