Following our discussion on the cfe dev list
(http://lists.llvm.org/pipermail/cfe-dev/2019-August/063054.html), I have added
a paragraph that is explicit about transformation options implying
the corresponding transformation.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Since this is user documentation, we should only add it here once it is true.
docs/LanguageExtensions.rst | ||
---|---|---|
3068–3069 ↗ | (On Diff #215031) | vectorize_width also "controls" a transformation. Is it that in our interpretation, vectorize(enable) overrides the profitability heuristic by taking out the "do not apply at all" option without setting any other option? |
Since this is user documentation, we should only add it here once it is true.
Yep, good point, I also wanted to capture our discussions on the list. But yes, let's hold this back until we're ready with the pragmas.
docs/LanguageExtensions.rst | ||
---|---|---|
3068–3069 ↗ | (On Diff #215031) | I think I need to think a little bit more about this:
but I would answer this with "yes". But just checking, what exactly do you mean with "do not apply at all option"? |
docs/LanguageExtensions.rst | ||
---|---|---|
3068–3069 ↗ | (On Diff #215031) | I unfortunately mixed two meanings of "option" here:
Let's take a look on the loop vectorizer. The profitability heuristic's job is too choose the "best" candidate out of the following list (independently of how LoopVectorize's heuristic is actually implemented; these might be decision made independently of each other, but as the user still sees one of the following outcomes): 0) no vectorization (the "do not apply at all" option/candidate) vectorize(enable) with remove 0) as a candidate. vecorize(disable) will remove all expect 0) as a candidate. The option/settings are vectorize_width and vectorize_predicate (and interleave_count). For instance vectorize_width(4) would remove 1) and 3)+ from the candidate list. vectorize_predicate(enable) takes any a) candidate from the list. What we were discussing was that these settings would remove 0) from the candidate list as well. |
Many thanks for your clarification!
What we were discussing was that these settings would remove 0) from the candidate list as well.
Yep, that's crystal clear now.
And my expectation would indeed be that this would be the case.
I have committed all my pragma patches, so now back to the last bit, this doc update.
This doc change should now reflect our implementation. Are we happy for this to go in?
docs/LanguageExtensions.rst | ||
---|---|---|
3069 ↗ | (On Diff #215031) | and there loop hints ==> and there are loop hints |