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: RFC: Add ADD_RESTRICT tree code


On Thu, Oct 13, 2011 at 11:21:58AM +0200, Richard Guenther wrote:
> I suggested that for a final patch we only add ADD_RESTRICT in the
> gimplifier for restrict qualified parameters, to make the inlining case
> work again.  ADD_RESTRICTs for casts to restrict qualified pointers
> I would add at parsing time, exactly when a literal cast to a
> restrict qualified pointer from a non-restrict qualified pointer happens
> in the source.  Everything else sounds too fragile IMHO.

I'd sum up my previous mail as noting that restricted pointers are objects,
so restrict is not property of expressions.  So e.g. I don't think
we should add ADD_RESTRICT (or, at least, not an ADD_RESTRICT with different
tag) on every assignment to a restrict pointer object.
E.g. the restrict tag for cases we don't handle yet currently
(GLOBAL_RESTRICT/PARM_RESTRICT) could be based on a DECL_UID (for fields
on FIELD_DECL uid, I think we are not duplicating the fields anywhere,
for VAR_DECLs based on DECL_ABSTRACT_ORIGIN's DECL_UID?) - by based mean
map those uids using some hash table into the uids of the artificial
restrict vars or something similar.
We probably can't use restrict when we have t->p where p is restrict field
or int *restrict *q with *q directly, it would be PTA's job to find that
out.  Of course if t above is restrict too, it could be handled, as well as
int *restrict *restrict q with *q.

	Jakub


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