This is the mail archive of the 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 RFC: Increase support for restrict qualifier

Daniel Berlin <> writes:

> second, how often does this actually set anything useful with restrict
> types (I assume the value is not interesting in any other cases)?

In functions which use the restrict qualifier, it does something
useful pretty often: just about every time the restricted pointer is
used other than as a simple *p.  The real question, which I don't know
the answer to, is how much that helps in common code.  (It does make a
significant difference in certain key functions at my current job.)

> ISTM you'd be better off doing what we do with DECL_VALUE_EXPR,
> DECL_DEBUG_EXPR, and DECL_INIT_PRIORITY, which is to use 1 bit to say
> whether it has an "underlying nonscalar decl", and a side hashtable to
> store the actual value.
> I say this because I imagine the number of DECL's which are restrict
> qualified, and thus, should have an underlying nonscalar-decl, is very
> small, and yet, you've added a field that is there for *all* decl's with
> rtl attached to them.
> This would also solve your field-decl problem, since you could throw the
> bit in the common part.

Makes sense.  It also reduces the cost quite a bit, which might make
it a good idea even if the benefit is small, pending a more complete


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