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

[Richard Smith via cfe-commits]

On Fri, Aug 21, 2015 at 10:35 AM, Michael Zolotukhin via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> Yes, I've considered a builitin as an alternative. In fact, I started with
> it as it was easier to implement, but then decided to switch to type
> attribute due to the following reasons:
>
> 1. ARM ACLE 2.0 mentions attribute. Though it's not a final version of the
> document, AFAIU, I still preferred to use it as an argument for
> type-attribute.
>

I don't think this argument carries much weight by itself: I would imagine
that the reason this was listed as a possible future direction was to
solicit feedback from implementers and users; I think it's entirely
appropriate for our feedback to be "this is the wrong approach".

Another objection I have to the ACLE proposal is that it puts the attribute
on a pointer type but applies it to the pointee. This seems to make various
reasonable use cases awkward to support. For instance, suppose I want to
have a global variable to which I perform nontemporal loads and stores: I
would need to take the address of that global, cast it to a nontemporal
pointer, and dereference that in order to get a nontemporal operation. It
would seem more natural to have the attribute apply to any type, and to
apply to loads and stores of that type. So:

  int __attribute__((nontemporal)) *p; // a pointer to a nontemporal int
  int * __attribute__((nontemporal)) q; // a pointer (within nontemporal
storage) to an int

  int x = *p; // normal load of p, nontemporal load of *p
  int y = *q; // nontemporal load of q, normal load of *q

2. Once we introduce a builtin, we'll have to support it forever (otherwise
> we could break someone's code). With the attribute the burden is much
> smaller, as we can just start ignoring it at any point if we need to - all
> the code will remain correct and compilable.
>

Whatever we do here, we will in practice support it forever. We already
have target-specific versions of these nontemporal operations that we
intend to support forever. The support cost of the builtins is lower than
that of a type attribute.

3. We'll need to have an intrinsic for every type + separate intrinsics for
> loads and stores. If we use the type attribute, one fits all.
>

Builtins can have custom type checking, and if they do they can effectively
be overloaded for any type. (See the atomic builtins for an example.)


> 4. While it's true, that this is more type of operation, than a type, I
> think in real use-cases a user would rarely need to use it on a single
> operation. I.e. nontemporal operations are usually used for processing bulk
> volumes of data, and probably this data is almost always is processed as a
> whole. That's why I think it's fine to mark the entire 'data' as
> nontemporal. And, if a user then wants to work with a small subset of it,
> she can use a usual (not nontemporal) pointer to it.
>

OK, so you'd require a cast to/from a nontemporal type at the entry/exit of
such code? That's probably reasonable, but like Aaron, I'm not really sure
what usage patterns will appear in the wild here.

5. Personally, I find the code using attributes more elegant than using
> builtins. Compare:
>
>   void foo(float *__attribute__((nontemporal)) dst,
>            float *__attribute__((nontemporal)) src1,
>            float *__attribute__((nontemporal)) src2) {
>     *dst = *src1 + *src2;
>   }
>
> and
>
>   void foo(float *dst, float *src1, float *src2) {
>     float s1 = __builtin_nontemporal_load(src1);
>     float s2 = __builtin_nontemporal_load(src2);
>     __builtin_nontemporal_store(s1 + s2, dst);
>   }
>
> But that said, in the end I'm open to other alternatives (including
> builtins), and this thread is just an attempt to find the best option.


I think my personal preference here would depend on how important it is
that these operations are nontemporal -- the latter formulation makes this
a lot more obvious (the reader really can't miss that fact).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150821/b9a2e923/attachment.html>