[PATCH] D12221: [RFC] Introduce `__attribute__((nontemporal))`.

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

In http://reviews.llvm.org/D12221#230263, @mzolotukhin wrote:

> Oh, I see. So, you meant something like this?
>
>   void foo(std::vector<float * __attribute__((nontemporal))> av, float * b, int N) {
>     for (auto a: av)      // << `a` doesn't have nontemporal attribute here
>       for (int i = 0; i < N; i++)
>         a[i] = b[i]+1;
>   }
>
>
> One can easily work around it by using an explicit type here (`float * __attribute__((nontemporal))` instead of `auto`), but I agree that disappeared attribute might be a surprise for the user. Do you think it would be a frequent case?


Yes, that's along the lines of what I was thinking. There are also other questions, as to whether a user would expect this code to work or not:

template <typename Ty>
void f(Ty *ptr);

template <typename Ty>
void f(Ty * __attribute__((nontemporal)) ptr);

I honestly don't know enough about nontemporal object usage patterns to really have a gut feeling for what patterns are likely to appear in the wild.

> BTW, there are other type attributes, which also suffer from the same issue, e.g. `vector_size`. What was the rationale of making them type attributes?


The usual rationale is that these attributes are targeting C code more than C++, or that the C++ use cases that would be strange to a user are unlikely to happen with realistic code. The discussion that's come up in the past when we touch on these is that Clang could perhaps use a pluggable type system that allows for more fine-grained control on whether an attribute participates as part of a type or not. A production-quality pluggable type system is a pretty large undertaking, and it's a bit research-y at this point, so I'm not proposing anything like that.

Similar questions that help decide is whether you should be able to overload on the type attribute, specialize templates on it, type identity, etc.

~Aaron


http://reviews.llvm.org/D12221