On Mon, Nov 7, 2011 at 10:45 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> Hi!
>
> I'd like to ping the restrict_based_on_field attribute patch:
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00135.html
>
> We currently don't do cast restricts and even if we do them again,
> as this attribute doesn't make the type __restrict it wouldn't
> affect those, it only affects parameters, if they are __restrict
> themselves what they point to, and global vars.
>
> IMHO it would be a pitty not to improve generated code for std::vector
> for 4.7.
The patch probably needs updating for the changes I committed and
it still says
"The patch is still incomplete,.."
It does look like this would map to the more general solution
explicitely specifying a restrict tag. That way we'd avoid the
funny field walkings (do you properly update the FIELD_DECL
parameter of the attribute when instantiating templates?)
--- libstdc++-v3/include/bits/stl_vector.h.jj 2011-08-18
08:36:12.000000000 +0200
+++ libstdc++-v3/include/bits/stl_vector.h 2011-10-03 15:45:26.000000000
+0200
@@ -77,9 +77,18 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
struct _Vector_impl
: public _Tp_alloc_type
{
- pointer _M_start;
- pointer _M_finish;
- pointer _M_end_of_storage;
+ /* These pointers act like restricted pointers, except that there
+ are 3 pointers pointing into the same array instead of just one.
+ That is, if any part of the array pointed by _M_start is
+ modified, it can be accessed through either pointers based
+ on the _M_start field, or based on the _M_finish field, or
+ _M_end_of_storage field. */
+ pointer _M_start
+ __attribute__((__restrict_based_on_field__ (_M_start)));
+ pointer _M_finish
+ __attribute__((__restrict_based_on_field__ (_M_start)));
+ pointer _M_end_of_storage
+ __attribute__((__restrict_based_on_field__ (_M_start)));
are we sure that no shallow copies of vectors are allowed? I'm thinking
of move constructors or so ...
Finally just the above is not very much testing coverage.
Thanks,
Richard.
