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

2015-09-10 Thread Michael Zolotukhin via cfe-commits
mzolotukhin abandoned this revision.
mzolotukhin added a comment.

We decided to go with an alternative way - with builtins instead of type 
attributes. The corresponding patch is http://reviews.llvm.org/D12313, and it's 
already reviewed and committed.


http://reviews.llvm.org/D12221



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2015-08-26 Thread Michael Zolotukhin via cfe-commits
mzolotukhin added a comment.

Hi,

I implemented builtin-based version in http://reviews.llvm.org/D12313 - could 
you please take a look?

Thanks,
Michael


http://reviews.llvm.org/D12221



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2015-08-21 Thread Michael Zolotukhin via cfe-commits
mzolotukhin added a comment.

Oh, I see. So, you meant something like this?

  void foo(std::vectorfloat * __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?

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?


http://reviews.llvm.org/D12221



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2015-08-21 Thread Richard Smith via cfe-commits
On Fri, Aug 21, 2015 at 12:14 PM, Michael Zolotukhin via cfe-commits 
cfe-commits@lists.llvm.org wrote:

 mzolotukhin added a comment.

 Oh, I see. So, you meant something like this?

   void foo(std::vectorfloat * __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?

 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?


vector_size produces a completely different type, with a different size,
alignment, different semantics and constraints for primitive operations,
and so on.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2015-08-21 Thread Michael Zolotukhin via cfe-commits
mzolotukhin added a comment.

Thanks for the feedback everyone!
I think at this point I'll try to return to builtins then. In my original patch 
I didn't have type overloading, so I'll need some time to add this. We can 
return back to type attributes later if we'd like to.

And do I understand it correctly, that we are talking about target-independent 
builtins?


http://reviews.llvm.org/D12221



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2015-08-20 Thread David Majnemer via cfe-commits
majnemer added a subscriber: majnemer.
majnemer added a comment.

What does it mean to have the attribute applied to non-pointer types like `int 
__attribute__((nontemporal)) i;` ?  The ACLE doesn't say but making it 
erroneous might make sense.  Perhaps it would be good to have a semantic test 
which uses `__attribute__((nontemporal))`.


http://reviews.llvm.org/D12221



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2015-08-20 Thread Richard Smith via cfe-commits
On Thu, Aug 20, 2015 at 6:39 PM, Michael Zolotukhin via cfe-commits 
cfe-commits@lists.llvm.org wrote:

 mzolotukhin created this revision.
 mzolotukhin added reviewers: hfinkel, doug.gregor, t.p.northover, ab,
 mcrosier.
 mzolotukhin added a subscriber: cfe-commits.
 Herald added a subscriber: aemerson.

 Currently there is no way to generate nontemporal memory accesses for some
 architectures, e.g. for AArch64. In contrast to x86, it doesn't have
 special
 intrinsics for this, and the suggested solution is using such attribute
 (see ARM
 ACLE 2.0, section 13.1.6). The attribute would result in generating
 '!nontemporal' attribute in IR, which then will (hopefully) live through
 optimizations till backend, where it will be lowered to a non-temporal
 instruction (for AArch64 - to STNP). I have committed a couple of patches
 for
 vectorizers to preserve this attribute, and it seems that no other
 transformation removes it.

 So, is introducing a new type attribute a right approach for this problem?


This seems like a property of an operation, rather than a property of a
type. Have you considered adding a __builtin_nontemporal_store builtin as
an alternative?

Also, since I don't have much experience in front-end, I'd appreciate any
 help
 with the patch itself to get it ready to be committed. Specifically, I
 currently
 have following questions:
 1) What tests should I add (examples would be appreciated)?
 2) How does one implements constraints on how the attribute can be used,
 what
 should be the constraints in this case, and how to properly implement them?
 3) How can I check if I covered all places where this attribute might be
 used in
 codegen? I.e. I seem to cover array-subscript and pointer-dereference
 expressions, which is probaly the only cases I care about, but I easily
 could
 miss something.

 Any other feedback is also welcome!

 Thanks,
 Michael

 http://reviews.llvm.org/D12221

 Files:
   include/clang/AST/Type.h
   include/clang/Basic/Attr.td
   lib/AST/Type.cpp
   lib/AST/TypePrinter.cpp
   lib/CodeGen/CGExpr.cpp
   lib/CodeGen/CGValue.h
   lib/CodeGen/CodeGenFunction.cpp
   lib/CodeGen/CodeGenFunction.h
   lib/Sema/SemaType.cpp
   test/CodeGen/nontemporal.cpp


 ___
 cfe-commits mailing list
 cfe-commits@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits