Re: YAMP: ivopts vs sizetype

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Fri, May 23, 2008 at 5:07 AM, DJ Delorie <dj@redhat.com> wrote:
>
> (yet another m32c-related problem)
>
> Something in ivopts is converting this:
>
>  ap.1_5 = ap_38 + 2;
>  ap.2_6 = (struct tiny *) ap_38;
>  SR.8_15 = ap.2_6->c;
>
> to this:
>
>  ap.1_5 = ap_38 + 2;
>  SR.8_15 = MEM[base: ap.1_5, offset: 65534];
>
> Now, recall that for -mcpu=m32c size_t is 16 bits but pointers are 24
> bits.  The above SHOULD have resulted in this:
>
>        mov.b   -2[a0], r0
>
> which I would have converted to this:
>
>        mov.b   16777214[a0], r0
>
> but instead I get this (and lots of testsuite errors):
>
>        mov.b   65536[a0], r0

Uh, so sizetype is 32bit but pointer displacements are 24bit?  :(

> So, there are two problems here:
>
> First, something in ivopts is using sizetype to manipulate pointers,
> which doesn't work.  I've seen plenty of cases where sizetype is used
> where the original pointer type could have been used (or even
> HOST_WIDE_INT) but couldn't track down the specific case that's the
> culprit.  Help?

Yeah, the affine combination code still has its problems with the
introduction of POINTER_PLUS - we also still get MEM_REFs with
integers as base pointer.

I hope at some point to have enough time to dig into this ...

> Second, this type of addressing is expensive on the m32c
> (displacements are always unsigned).  It would have been far better to
> use ap_38 and not had a displacement (or had a small positive one).
> Is there a way to tell SSA (or gcc in general) that negative
> displacements are expensive?

So negative displacements will be 24bit displacements (expensive) and
small positive displacements will fit in 16bit (or even 8bit) displacements?

I don't think you can tell that, but maybe look into tree-ssa-address.c where
it asks the target for costs via building some rtx-en.

Richard.