This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/5] Named address spaces: core middle-end support


On Thu, Aug 20, 2009 at 5:07 PM, Ulrich Weigand<uweigand@de.ibm.com> wrote:
> Richard Guenther wrote:
>
>> > The question is how to represent this operation at the
>> > tree level ... =A0 If CONVERT_EXPR (or NOP_EXPR) are not
>> > suitable for this, do you have another suggestion?
>>
>> EA_CONVERT_EXPR or EA_TRANSLATE_EXPR? ?Overloading
>> an existing no-op one seems to be confusing.
>
> I see. ?It wasn't clear to me that CONVERT_EXPR was supposed
> to be a no-op (it isn't a no-op for floating-point types?) ...

Floating point types use FIX_TRUNC_EXPR and FLOAT_EXPR.
NOP_EXPR and CONVERT_EXPR are not a no-op if they
convert between types with different precision (in which case
they are truncating or extending).  Otherwise they are bit-pattern
preserving but only valid on integral types and pointer types.

> It seems for the new fixed-point operations we also got a
> new tree code FIXED_CONVERT_EXPR. ?It would certainly be
> fine with me to add a new tree code for pointer conversions
> as well.
>
> However, I don't think EA_... is a good name; the "__ea"
> terminology is SPU specific and should not appear in the
> middle_end.
>
> What about POINTER_CONVERT_EXPR ?

But it's not for general pointers - conversions between pointers
to the same address space can still use CONVERT/NOP_EXPR.

So it is in fact named address space specific.  So maybe
CHANGE_ADDRESS_SPACE_EXPR?

> I'll try to adapt the patch accordingly.

Thanks,
Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]