Re: SUBREG problems

[Joern Rennecke <amylaar at redhat dot com>]

> 
> 
> Hi ALL
>  I am working for a new gcc port.I have a small
> problem
>  with subregs. I am still to confirm whether this
> problem is addressed by some body or not.
> 
>   On my machine the UNITS_PER_WORD is 2 and I made
> longs as 32 bits. So, when they are in registers they 
>  need two consecutive registers. I am doing this.
> 
>   ALl the opeartions on the machine are 16bit. So, I
> am
> splitting the long operations in to two 16 bit
> operations.
> 
>    The problem is with the compare and branch
> operations.....
> 
>  I have a test program ......
> 
>    int main ()
>    {
>      register long x = 10;
> 
>      if (x == 10)
>        return 0;
>       else
>        return 1;
>    }
> 
>   Here the problem is when  I access the low part and
>  high parts of op for my cmp/branch operations 
>   the look like
> 
> insn 10 8 11 (set (cc0)
>         (compare (subreg:HI (reg/v:SI 53) 0)
>             (const_int 0 [0x0]))) 15 {cmphi_1} (nil)
>     (nil))
> 
>  
> (insn 12 11 13 (set (cc0)
>         (compare (subreg:HI (reg/v:SI 53) 1)
>             (const_int 10 [0xa]))) 15 {cmphi_1} (nil)
>     (nil))
> 
> 
> . When they end up in memory both subregs refer to the
> 
>  low parts only. if x is at (ix -4), both refer to (ix
> -4) to (ix -2) only. I do n't know where it is going
> wrong.......
> 
>   Do I need to add some thing in the gen_lowpart and
> gen_highpart ??
> 
> 
>  Could some body point me at the right place where to
> look for this problem.......

As you start out with a pseudo register, I would expect the stack slot
allocation to be done from alter_reg.  You could set a breakpoint
there and compare before / after dumps for insns 10 and 12.  For that
matter, it seems surprising that the only user level variable would
be spilled; or are you actually using a lager testcase?

Anyways, if youare using gdb on a host where it supports hardware
watchpoints, there is also another technique that allows you to find
out where things go wrong:
print &cfun->emit->x_regno_reg_rtx[53]->code
and set a hardware watchpoint on the dereferenced address to see where
the pseudo is spilled.  Likewise, you can set hardware watchpoints to
find out where particular pieces of rtl in the insn stream are altered.