dmgreen added a comment.
Thanks.
Repository:
rC Clang
https://reviews.llvm.org/D47267
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC338566: [UnrollAndJam] Add unroll_and_jam pragma handling
(authored by dmgreen, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D47267?vs=158219=158537#toc
Repository:
rC Clang
Meinersbur accepted this revision.
Meinersbur added a comment.
This revision is now accepted and ready to land.
LGTM
Comment at: lib/Sema/SemaStmtAttr.cpp:183
{nullptr, nullptr}};
-
for (const auto *I : Attrs) {
[nit] unrelated
dmgreen updated this revision to Diff 158219.
dmgreen added a comment.
Rebase.
Michael, you happy with this part?
The pragma clang loop part is off in https://reviews.llvm.org/D47320. Let me
know if/when I should do something with that.
https://reviews.llvm.org/D47267
Files:
dmgreen added a comment.
In https://reviews.llvm.org/D47267#1123318, @hfinkel wrote:
> I have a preference for using the underscores as our primary spelling. I
> think that it's easier to read.
I agree with it being easier to read.
> I prefer we have a different syntax that we can use
hfinkel added a comment.
In https://reviews.llvm.org/D47267#1123038, @Meinersbur wrote:
> In https://reviews.llvm.org/D47267#1123013, @dmgreen wrote:
>
> > I see your point about the mix of underscores. "nounroll_and_jam" also
> > comes from the Intel docs, and theres already "nounroll" vs
Meinersbur added a comment.
In https://reviews.llvm.org/D47267#1123013, @dmgreen wrote:
> I see your point about the mix of underscores. "nounroll_and_jam" also comes
> from the Intel docs, and theres already "nounroll" vs "unroll". The "no"
> becomes a qualifier on "unroll_and_jam".
dmgreen added a comment.
I quite like the UnrollAndFuse naming. I'd not heard that the xlc compiler
called it that. The UnrollAndJam pass was origin named that before I renamed
for similar reasons (UnrollAndJam being more well known).
I see your point about the mix of underscores.
Meinersbur added a comment.
In https://reviews.llvm.org/D47267#1122425, @dmgreen wrote:
> I noticed in the paper that you used the name "unrollandjam", minus
> underscores. Should I change this use that spelling here? I have no strong
> opinion of one over the other (was just using what I had
dmgreen added a comment.
Thanks.
I noticed in the paper that you used the name "unrollandjam", minus
underscores. Should I change this use that spelling here? I have no strong
opinion of one over the other (was just using what I had found from the Intel
docs).
Meinersbur added a comment.
The RFC: https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html
https://reviews.llvm.org/D47267
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Meinersbur added a comment.
Yes, this is what I had in mind. Thank you.
I am preparing an RFC on what I am trying to do. This should clarify our goals
and to what extend `#pragma clang loop` conflicts with it.
https://reviews.llvm.org/D47267
___
dmgreen updated this revision to Diff 148393.
dmgreen added a comment.
This splits out the pragma clang loop unroll_and_jam handling into
https://reviews.llvm.org/D47320, for if/when we need it. Which I believe is
what you wanted, correct me if I'm wrong.
https://reviews.llvm.org/D47267
SjoerdMeijer added a comment.
Just out of curiousity:
- How do you plan to implement this? Are you going to generate from the pragma
some sort of "script" that dictates the transformation order which is going to
be fed to the pass manager?
- About the stacking of pragmas, in your example you
Meinersbur added a comment.
In https://reviews.llvm.org/D47267#1109912, @dmgreen wrote:
> > Could we maybe disable the #pragma clang loop unroll_and_jam spelling ftm
> > to avoid compatibility issues?
>
> Sure, I'm not against. It sounds like you have opinions on how this should
> work. That's
dmgreen added a comment.
> In my experience, they are used.
Good to know, cheers.
> Could we maybe disable the #pragma clang loop unroll_and_jam spelling ftm to
> avoid compatibility issues?
Sure, I'm not against. It sounds like you have opinions on how this should
work. That's good. If
Meinersbur added a comment.
This is straightforward in that it clones the implementation of `#pragma
unroll` for `unroll_and_jam`.
Hence, it also shares the same problem of clang's LoopHints, namely that the
order of loop transformations (if there are multiple on the same loop: loop
hfinkel added a comment.
> I have some doubts whether this will ever be used sensibly in the real world,
> but can
> be useful for testing and was not difficult to put together.
I definitely support having pragmas for these kinds of loop transformations. In
my experience, they are used.
dmgreen created this revision.
dmgreen added reviewers: SjoerdMeijer, hfinkel, tyler.nowicki, anemet, alexfh.
Herald added a subscriber: zzheng.
This adds support for the unroll_and_jam pragma, to go with
https://reviews.llvm.org/D41953. The name of
the pragma is copied from the Intel compiler,
19 matches
Mail list logo
