Thank you for the comment!

2014-08-13 15:55 GMT+06:00 Richard Biener <richard.guent...@gmail.com>:
> On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev <gareevro...@gmail.com> wrote:
>> If I’m not mistaken all tree nodes, which have pointer type, can be
>> divided into two groups:  the type is a  is a pointer to data member
>> (TYPE_PTRMEM_P is true for it),  the type is a pointer type, and the
>> pointee is not a data member (TYPE_PTR_P is true for it).
>
> Both are C++ frontend concepts and not relevant for the middle-end
> and thus GRAPHITE.
>
>  I think that
>> we’re interested in disabling of the second group handling. It can
>> also be divided into two  groups:  the type is a pointer to function
>> type (TYPE_PTRFN_P is true for it), the type is a pointer to object
>> type (TYPE_PTROB_P is true for it). In my opinion, the second one is
>> worth to be considered. It contains, for example, nop_expr (these
>> nodes are used to represent conversions that do not require any
>> code-generation) integer_cst (these nodes represent integer
>> constants), ssa_name. I haven’t found all types, which are contained
>> in it. However, I think that we could disable other types, if it is
>> necessary in the future.
>>
>>> What we should do later is to build a run-time check that ensures
>>> no pointer overflow is happening and then just create code without it.
>
> I think you can assume that pointers don't overflow.
>
> Richard.
>
>> I think that it is better to do this when the pointer handling is completed.
>>
>> I’ve attached a Change_Log, which corresponds to the previous patch.
>> Are they fine for trunk? Could we give a headsup on the GCC mailing
>> list and ask other people to try the new isl support in case this
>> patch is committed?
>>
>> --
>>                                     Cheers, Roman Gareev.



-- 
                                    Cheers, Roman Gareev.

Reply via email to