m32c support for named addr spaces branch

[Richard Guenther]

On Tue, Oct 27, 2009 at 7:22 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> Richard Guenther wrote:
>
>> On Tue, Oct 20, 2009 at 8:09 PM, DJ Delorie <dj@redhat.com> wrote:
>> > My preference is this: pointers and integers are NOT interchangable.
>> > Pointer offsets must be sign or zero extended according to their
>> > underlying types before being added to pointers.  If I add -1 to a
>> > pointer, it had better result in a pointer that's one less than the
>> > previous value, not 65536 more.
>>
>> Well, you are right.  sizetype originally only was present in sizetype-only
>> operations where the above would not have been an issue.  Now
>> with POINTER_PLUS_EXPR we introduced a mixed-type operation
>> between pointer types and sizetype - which was obviously a mistake.
>> Thus, the correct thing to do is to transition POINTER_PLUS_EXPR
>> away from using sizetype but instead use regular integer types for
>> the offset (I'm not sure if constraining the offset type to a single type
>> was a good idea - it probably was good to catch transition errors).
>
> I now seem to be running into a related problem with __ea on SPU, in a
> loop where the loop optimizer decides to use a DImode IV to implement
> a 64-bit __ea pointer.
>
> This causes create_mem_ref to be called with an affine combination
> that contains only a single value, of 64-bit integral type.
>
> Because this is not a pointer type, addr_to_parts interprets this
> value as "index", not "base".  (I'm not quite sure I understand
> how this is intended to work anyway: it seems to me that loop IVs
> use (nearly?) always integral types.  Why does move_pointer_to_base
> check for pointer type then?)
>
> But add_to_parts will always convert "index" to sizetype.  In the
> case where the incoming type is larger than sizetype, this leads
> to the value being silently truncated.  This behaviour seems to
> be mandated by the definition of TARGET_MEM_REF, which currently
> requires all elements (except base) to be of type sizetype ...
>
>> But I don't see anyone doing the required work.
>
> I guess I can try to look into this.  Do you have any further
> suggestions what needs to be done?

No.  The main issue is forcing all pointer offsets to sizetype
by POINTER_PLUS_EXPR (and TARGET_MEM_REF as you
noticed).  I expect that most of the fallout if you remove this
restriction and allow arbitrary integer types as offset will
be in fold and ivopts.  I would expect that it also might uncover
missing canonicalization for constant offsets and thus
missed CSE opportunities at the tree level for example.

You will also hit the interesting case that you'd need to do
type promotion in the middle-end if you want to re-associate
for example (ptr + short) + int (which would be valid then).

Thus, I would allow any offset type for POINTER_PLUS_EXPR
but define precisely how it is supposed to be expanded.
Which would be (implicitly) sign-/zero-extend the offset
according to its signedness to pointer width and then
perform the addition.  So the short + int case would have
to be promoted the same, (intptr_t)short + (intptr_t)int.

Thanks for considering to do the work!

Richard.

> Thanks,
> Ulrich
>
> --
>  Dr. Ulrich Weigand
>  GNU Toolchain for Linux on System z and Cell BE
>  Ulrich.Weigand@de.ibm.com
>