Behaviour of loop pragmas and transformation options

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Behaviour of loop pragmas and transformation options

Nathan Ridge via cfe-dev
We have recently added support for a new loop pragma 'vectorize_predicate' [1].
During review of the LLVM part that does the actual transformation [2], the
question was raised if 'vectorize_predicate' should imply 'vectorize(enable)'.
I agree that this is indeed what users would most likely expect and so I
created a patch for that [3].

During review of [3], Florian mentioned bug report [4] supporting the case that
users indeed expect that more specific pragmas such as e.g. vectorize_width(4)
should imply vectorize(enable), but this is currently not the case.  But our
docs for example mention: "The following example implicitly enables
vectorization and interleaving by specifying a vector width and interleaving
count", and so we have an inconsistency in the docs and implementation. But as
I have e.g. no clue what the behaviour could be of "vectorize(disable)
vectorize_predicate(enable)", I would say the docs are right and the
implementation is wrong.

Michael mentioned that the situation with for example loop unroll pragmas
'unroll(enable) unroll_count(4)' is not very different. Pragma 'unroll_count'
also does not set 'llvm.loop.unroll.enable', but it is handled by the
LoopUnroll pass itself and so we end up with checks like this:

    bool ExplicitUnroll = PragmaCount > 0 || PragmaFullUnroll ||
                          PragmaEnableUnroll || UserUnrollCount;

And again, this is very similar to 'vectorize_width', and we have different
checks to see if vectorization is enabled.

Because of the many inconsistencies, we came to the conclusion in [3] that we
don't know how know how to (best) implement that setting an transformation
option implies setting the transformation.

My proposal would be that the transformation options imply the transformations
by setting the enable flag of that transformation. Thus, vectorize options
vectorize_width, vectorize_predicate, etc., set vectorize(enable), and unroll
option unroll count set unroll(enable).

Any thoughts on this welcome.


[1] https://reviews.llvm.org/rL366989
[2] https://reviews.llvm.org/D65197
[3] https://reviews.llvm.org/D65776
[4] https://bugs.llvm.org/show_bug.cgi?id=27643

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Behaviour of loop pragmas and transformation options

Nathan Ridge via cfe-dev


On 8/7/19 12:25 AM, Sjoerd Meijer via cfe-dev wrote:
We have recently added support for a new loop pragma 'vectorize_predicate' [1].
During review of the LLVM part that does the actual transformation [2], the
question was raised if 'vectorize_predicate' should imply 'vectorize(enable)'.
I agree that this is indeed what users would most likely expect and so I
created a patch for that [3].

During review of [3], Florian mentioned bug report [4] supporting the case that
users indeed expect that more specific pragmas such as e.g. vectorize_width(4)
should imply vectorize(enable), but this is currently not the case.  But our
docs for example mention: "The following example implicitly enables
vectorization and interleaving by specifying a vector width and interleaving
count", and so we have an inconsistency in the docs and implementation. But as
I have e.g. no clue what the behaviour could be of "vectorize(disable)
vectorize_predicate(enable)", I would say the docs are right and the
implementation is wrong.

Michael mentioned that the situation with for example loop unroll pragmas
'unroll(enable) unroll_count(4)' is not very different. Pragma 'unroll_count'
also does not set 'llvm.loop.unroll.enable', but it is handled by the
LoopUnroll pass itself and so we end up with checks like this:

    bool ExplicitUnroll = PragmaCount > 0 || PragmaFullUnroll ||
                          PragmaEnableUnroll || UserUnrollCount;

And again, this is very similar to 'vectorize_width', and we have different
checks to see if vectorization is enabled.

Because of the many inconsistencies, we came to the conclusion in [3] that we
don't know how know how to (best) implement that setting an transformation
option implies setting the transformation.

My proposal would be that the transformation options imply the transformations
by setting the enable flag of that transformation. Thus, vectorize options
vectorize_width, vectorize_predicate, etc., set vectorize(enable), and unroll
option unroll count set unroll(enable).
I second this.  The complexities of which pragmas enable which transforms should be handled entirely in Clang, with Clang responsible for emitting a consistent set of metadata flags to LLVM. 

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Behaviour of loop pragmas and transformation options

Nathan Ridge via cfe-dev
Thanks for your reply. This direction looked sensible, and I wanted to check if we weren't missing anything.

Cheers,
Sjoerd.

From: Philip Reames <[hidden email]>
Sent: 09 August 2019 23:47
To: Sjoerd Meijer <[hidden email]>; [hidden email] <[hidden email]>
Cc: nd <[hidden email]>
Subject: Re: [cfe-dev] Behaviour of loop pragmas and transformation options
 


On 8/7/19 12:25 AM, Sjoerd Meijer via cfe-dev wrote:
We have recently added support for a new loop pragma 'vectorize_predicate' [1].
During review of the LLVM part that does the actual transformation [2], the
question was raised if 'vectorize_predicate' should imply 'vectorize(enable)'.
I agree that this is indeed what users would most likely expect and so I
created a patch for that [3].

During review of [3], Florian mentioned bug report [4] supporting the case that
users indeed expect that more specific pragmas such as e.g. vectorize_width(4)
should imply vectorize(enable), but this is currently not the case.  But our
docs for example mention: "The following example implicitly enables
vectorization and interleaving by specifying a vector width and interleaving
count", and so we have an inconsistency in the docs and implementation. But as
I have e.g. no clue what the behaviour could be of "vectorize(disable)
vectorize_predicate(enable)", I would say the docs are right and the
implementation is wrong.

Michael mentioned that the situation with for example loop unroll pragmas
'unroll(enable) unroll_count(4)' is not very different. Pragma 'unroll_count'
also does not set 'llvm.loop.unroll.enable', but it is handled by the
LoopUnroll pass itself and so we end up with checks like this:

    bool ExplicitUnroll = PragmaCount > 0 || PragmaFullUnroll ||
                          PragmaEnableUnroll || UserUnrollCount;

And again, this is very similar to 'vectorize_width', and we have different
checks to see if vectorization is enabled.

Because of the many inconsistencies, we came to the conclusion in [3] that we
don't know how know how to (best) implement that setting an transformation
option implies setting the transformation.

My proposal would be that the transformation options imply the transformations
by setting the enable flag of that transformation. Thus, vectorize options
vectorize_width, vectorize_predicate, etc., set vectorize(enable), and unroll
option unroll count set unroll(enable).
I second this.  The complexities of which pragmas enable which transforms should be handled entirely in Clang, with Clang responsible for emitting a consistent set of metadata flags to LLVM. 

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Behaviour of loop pragmas and transformation options

Nathan Ridge via cfe-dev
In reply to this post by Nathan Ridge via cfe-dev
Hi Sjoerd,

Thanks for writing this up! As Philip already mentioned, I think clang should handle enabling transforms by setting the corresponding `enable` metadata when more specific transform pragmas are used. This is what the expected behavior is according to the docs and the current implementation leads to surprising outcomes like in PR27643.

We probably should also enable required transformations like loop rotation when vectorization was requested via a pragma, as  LoopVectorize requires rotated loops. Adam put up a patch for that a while ago https://reviews.llvm.org/D59832.

Cheers,
Florian


On Aug 7, 2019, at 08:25, Sjoerd Meijer via cfe-dev <[hidden email]> wrote:

We have recently added support for a new loop pragma 'vectorize_predicate' [1].
During review of the LLVM part that does the actual transformation [2], the
question was raised if 'vectorize_predicate' should imply 'vectorize(enable)'.
I agree that this is indeed what users would most likely expect and so I
created a patch for that [3].

During review of [3], Florian mentioned bug report [4] supporting the case that
users indeed expect that more specific pragmas such as e.g. vectorize_width(4)
should imply vectorize(enable), but this is currently not the case.  But our
docs for example mention: "The following example implicitly enables
vectorization and interleaving by specifying a vector width and interleaving
count", and so we have an inconsistency in the docs and implementation. But as
I have e.g. no clue what the behaviour could be of "vectorize(disable)
vectorize_predicate(enable)", I would say the docs are right and the
implementation is wrong.

Michael mentioned that the situation with for example loop unroll pragmas
'unroll(enable) unroll_count(4)' is not very different. Pragma 'unroll_count'
also does not set 'llvm.loop.unroll.enable', but it is handled by the
LoopUnroll pass itself and so we end up with checks like this:

    bool ExplicitUnroll = PragmaCount > 0 || PragmaFullUnroll ||
                          PragmaEnableUnroll || UserUnrollCount;

And again, this is very similar to 'vectorize_width', and we have different
checks to see if vectorization is enabled.

Because of the many inconsistencies, we came to the conclusion in [3] that we
don't know how know how to (best) implement that setting an transformation
option implies setting the transformation.

My proposal would be that the transformation options imply the transformations
by setting the enable flag of that transformation. Thus, vectorize options
vectorize_width, vectorize_predicate, etc., set vectorize(enable), and unroll
option unroll count set unroll(enable).

Any thoughts on this welcome.


[4] https://bugs.llvm.org/show_bug.cgi?id=27643
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Behaviour of loop pragmas and transformation options

Nathan Ridge via cfe-dev
In reply to this post by Nathan Ridge via cfe-dev
Hi,

if the consensus is that `vectorize_predicate()` should also set
`llvm.loop.vectorize.enable`, could you change the patch to apply this
also to `vectorize_width()`, `interleave_count()`?

I don think we need to change unroll_count() atm.

Michael




Am Mi., 7. Aug. 2019 um 02:25 Uhr schrieb Sjoerd Meijer via cfe-dev
<[hidden email]>:

>
> We have recently added support for a new loop pragma 'vectorize_predicate' [1].
> During review of the LLVM part that does the actual transformation [2], the
> question was raised if 'vectorize_predicate' should imply 'vectorize(enable)'.
> I agree that this is indeed what users would most likely expect and so I
> created a patch for that [3].
>
> During review of [3], Florian mentioned bug report [4] supporting the case that
> users indeed expect that more specific pragmas such as e.g. vectorize_width(4)
> should imply vectorize(enable), but this is currently not the case.  But our
> docs for example mention: "The following example implicitly enables
> vectorization and interleaving by specifying a vector width and interleaving
> count", and so we have an inconsistency in the docs and implementation. But as
> I have e.g. no clue what the behaviour could be of "vectorize(disable)
> vectorize_predicate(enable)", I would say the docs are right and the
> implementation is wrong.
>
> Michael mentioned that the situation with for example loop unroll pragmas
> 'unroll(enable) unroll_count(4)' is not very different. Pragma 'unroll_count'
> also does not set 'llvm.loop.unroll.enable', but it is handled by the
> LoopUnroll pass itself and so we end up with checks like this:
>
>     bool ExplicitUnroll = PragmaCount > 0 || PragmaFullUnroll ||
>                           PragmaEnableUnroll || UserUnrollCount;
>
> And again, this is very similar to 'vectorize_width', and we have different
> checks to see if vectorization is enabled.
>
> Because of the many inconsistencies, we came to the conclusion in [3] that we
> don't know how know how to (best) implement that setting an transformation
> option implies setting the transformation.
>
> My proposal would be that the transformation options imply the transformations
> by setting the enable flag of that transformation. Thus, vectorize options
> vectorize_width, vectorize_predicate, etc., set vectorize(enable), and unroll
> option unroll count set unroll(enable).
>
> Any thoughts on this welcome.
>
>
> [1] https://reviews.llvm.org/rL366989
> [2] https://reviews.llvm.org/D65197
> [3] https://reviews.llvm.org/D65776
> [4] https://bugs.llvm.org/show_bug.cgi?id=27643
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Behaviour of loop pragmas and transformation options

Nathan Ridge via cfe-dev
Hi,

Sure, I won't mind fixing these other cases too while I am at it.
I think my only preference would be to make one functional change at a time (fix one pragma (option) at a time), because this has turned into a little project  on itself and dealing with issues would be easier, unless a big-bang change would be preferred in this case for some reason and then I will address them all in D65776.

I think one thing we haven't discussed yet is conflicting combinations like:

    vectorize(enable) vectorize_width(1)

Should this enable of disable vectorisation? This is now important when an option implies setting the transformation.  I think it probably makes most sense that enabling/disabling the transformation should take precedence over setting the transformation options, and so in this example vectorisation should be enabled. With this logic, the predicate hint is ignored because vectorisation is disabled in this case:

    vectorize(disable) vectorize_predicate(enable)

which is what is being proposed in D65776.

After fixing the Clang behaviour, it would be good to revise the LLVM parts that check these transformations and options, to check things are consistent or can be simplified like the code example in the first message.

Cheers,
Sjoerd.


From: Michael Kruse <[hidden email]>
Sent: 12 August 2019 22:42
To: Sjoerd Meijer <[hidden email]>
Cc: [hidden email] <[hidden email]>; nd <[hidden email]>
Subject: Re: [cfe-dev] Behaviour of loop pragmas and transformation options
 
Hi,

if the consensus is that `vectorize_predicate()` should also set
`llvm.loop.vectorize.enable`, could you change the patch to apply this
also to `vectorize_width()`, `interleave_count()`?

I don think we need to change unroll_count() atm.

Michael




Am Mi., 7. Aug. 2019 um 02:25 Uhr schrieb Sjoerd Meijer via cfe-dev
<[hidden email]>:
>
> We have recently added support for a new loop pragma 'vectorize_predicate' [1].
> During review of the LLVM part that does the actual transformation [2], the
> question was raised if 'vectorize_predicate' should imply 'vectorize(enable)'.
> I agree that this is indeed what users would most likely expect and so I
> created a patch for that [3].
>
> During review of [3], Florian mentioned bug report [4] supporting the case that
> users indeed expect that more specific pragmas such as e.g. vectorize_width(4)
> should imply vectorize(enable), but this is currently not the case.  But our
> docs for example mention: "The following example implicitly enables
> vectorization and interleaving by specifying a vector width and interleaving
> count", and so we have an inconsistency in the docs and implementation. But as
> I have e.g. no clue what the behaviour could be of "vectorize(disable)
> vectorize_predicate(enable)", I would say the docs are right and the
> implementation is wrong.
>
> Michael mentioned that the situation with for example loop unroll pragmas
> 'unroll(enable) unroll_count(4)' is not very different. Pragma 'unroll_count'
> also does not set 'llvm.loop.unroll.enable', but it is handled by the
> LoopUnroll pass itself and so we end up with checks like this:
>
>     bool ExplicitUnroll = PragmaCount > 0 || PragmaFullUnroll ||
>                           PragmaEnableUnroll || UserUnrollCount;
>
> And again, this is very similar to 'vectorize_width', and we have different
> checks to see if vectorization is enabled.
>
> Because of the many inconsistencies, we came to the conclusion in [3] that we
> don't know how know how to (best) implement that setting an transformation
> option implies setting the transformation.
>
> My proposal would be that the transformation options imply the transformations
> by setting the enable flag of that transformation. Thus, vectorize options
> vectorize_width, vectorize_predicate, etc., set vectorize(enable), and unroll
> option unroll count set unroll(enable).
>
> Any thoughts on this welcome.
>
>
> [1] https://reviews.llvm.org/rL366989
> [2] https://reviews.llvm.org/D65197
> [3] https://reviews.llvm.org/D65776
> [4] https://bugs.llvm.org/show_bug.cgi?id=27643
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Behaviour of loop pragmas and transformation options

Nathan Ridge via cfe-dev
Hi,

On Aug 13, 2019, at 09:56, Sjoerd Meijer via cfe-dev <[hidden email]> wrote:

Hi,

Sure, I won't mind fixing these other cases too while I am at it.
I think my only preference would be to make one functional change at a time (fix one pragma (option) at a time), because this has turned into a little project  on itself and dealing with issues would be easier, unless a big-bang change would be preferred in this case for some reason and then I will address them all in D65776. 


Addressing it on a patch-per-pragma sounds good, thanks for picking this up!


I think one thing we haven't discussed yet is conflicting combinations like:


I think we should agree on something like the following as a general rule to deal with such cases: 

More specific transformation pragmas (e.g. vector_width) imply the transformation is enabled, as if it was enabled via the corresponding explicit pragma (e.g. vectorize(enable)). If the transformation is explicitly disabled  (e.g. vectorize(disable)), that takes precedence over pragmas implicitly enabling it.

We should warn for obvious conflicts (like your second example), but we probably should not not put too much knowledge about the specific parameters into clang. 


    vectorize(enable) vectorize_width(1)

IMO we should enable the transformation and set vector_width=1 in the metadata. This might not make too much sense (it instructs LoopVectorize to only do interleaving), but I do not think it would be a good idea to add too much logic to validate parameter combinations to clang. We can always provide information via optimization remarks from the transforms.


Should this enable of disable vectorisation? This is now important when an option implies setting the transformation.  I think it probably makes most sense that enabling/disabling the transformation should take precedence over setting the transformation options, and so in this example vectorisation should be enabled. With this logic, the predicate hint is ignored because vectorisation is disabled in this case:

    vectorize(disable) vectorize_predicate(enable)

IMO it makes sense for the more explicit pragma (vectorize(disable)) to take precedence over the one that implicitly enables vectorization. We should disable vectorization via metadata.


Cheers,
Florian

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Behaviour of loop pragmas and transformation options

Nathan Ridge via cfe-dev
Hi Florian,

I mostly agree with this summary:

> More specific transformation pragmas (e.g. vector_width) imply the transformation is enabled, as if it was enabled via the corresponding explicit pragma (e.g. vectorize(enable)). If the transformation is explicitly disabled  (e.g. vectorize(disable)), that takes precedence over pragmas implicitly enabling it.

 Just a few minor corrections. In the the last sentence, "implicitly enabling it" should be "implying it".

I think we can simplify things by simply not mentioning "explicit" or "more specific" etc. if we define:
  • transformations, e.g.: vectorize, unroll, etc.,
  • transformations options, e.g.: vectorize_width, vectorize_predicate, unroll_count, etc.

So the summary becomes something like:

Pragmas setting transformation options (e.g. vector_width) imply the transformation is enabled, as if it was enabled via the corresponding transformation pragma (e.g. vectorize(enable)). If the transformation is disabled  (e.g. vectorize(disable)), that takes precedence over transformations option pragmas implying that transformation.

With this definition,

>> vectorize(enable) vectorize_width(1)
>
> IMO we should enable the transformation and set vector_width=1 in the metadata.

I agree that this is could then be the expected behaviour (you could also argue that setting a value is not the same as disabling it). And this example is also straightforward indeed:

>> vectorize(disable) vectorize_predicate(enable)
>>
> IMO it makes sense for the more explicit pragma (vectorize(disable)) to take precedence over the one that implicitly enables vectorization.

It just follows from the definition.


Cheers,
Sjoerd.


From: [hidden email] <[hidden email]> on behalf of Florian Hahn <[hidden email]>
Sent: 13 August 2019 10:24
To: Sjoerd Meijer <[hidden email]>
Cc: Michael Kruse <[hidden email]>; nd <[hidden email]>; [hidden email] <[hidden email]>
Subject: Re: [cfe-dev] Behaviour of loop pragmas and transformation options
 
Hi,

On Aug 13, 2019, at 09:56, Sjoerd Meijer via cfe-dev <[hidden email]> wrote:

Hi,

Sure, I won't mind fixing these other cases too while I am at it.
I think my only preference would be to make one functional change at a time (fix one pragma (option) at a time), because this has turned into a little project  on itself and dealing with issues would be easier, unless a big-bang change would be preferred in this case for some reason and then I will address them all in D65776. 


Addressing it on a patch-per-pragma sounds good, thanks for picking this up!


I think one thing we haven't discussed yet is conflicting combinations like:


I think we should agree on something like the following as a general rule to deal with such cases: 

More specific transformation pragmas (e.g. vector_width) imply the transformation is enabled, as if it was enabled via the corresponding explicit pragma (e.g. vectorize(enable)). If the transformation is explicitly disabled  (e.g. vectorize(disable)), that takes precedence over pragmas implicitly enabling it.

We should warn for obvious conflicts (like your second example), but we probably should not not put too much knowledge about the specific parameters into clang. 


    vectorize(enable) vectorize_width(1)

IMO we should enable the transformation and set vector_width=1 in the metadata. This might not make too much sense (it instructs LoopVectorize to only do interleaving), but I do not think it would be a good idea to add too much logic to validate parameter combinations to clang. We can always provide information via optimization remarks from the transforms.


Should this enable of disable vectorisation? This is now important when an option implies setting the transformation.  I think it probably makes most sense that enabling/disabling the transformation should take precedence over setting the transformation options, and so in this example vectorisation should be enabled. With this logic, the predicate hint is ignored because vectorisation is disabled in this case:

    vectorize(disable) vectorize_predicate(enable)

IMO it makes sense for the more explicit pragma (vectorize(disable)) to take precedence over the one that implicitly enables vectorization. We should disable vectorization via metadata.


Cheers,
Florian

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Behaviour of loop pragmas and transformation options

Nathan Ridge via cfe-dev
In reply to this post by Nathan Ridge via cfe-dev


On 8/13/19 4:24 AM, Florian Hahn via cfe-dev wrote:
Hi,

On Aug 13, 2019, at 09:56, Sjoerd Meijer via cfe-dev <[hidden email]> wrote:

Hi,

Sure, I won't mind fixing these other cases too while I am at it.
I think my only preference would be to make one functional change at a time (fix one pragma (option) at a time), because this has turned into a little project  on itself and dealing with issues would be easier, unless a big-bang change would be preferred in this case for some reason and then I will address them all in D65776. 


Addressing it on a patch-per-pragma sounds good, thanks for picking this up!


I think one thing we haven't discussed yet is conflicting combinations like:


I think we should agree on something like the following as a general rule to deal with such cases: 

More specific transformation pragmas (e.g. vector_width) imply the transformation is enabled, as if it was enabled via the corresponding explicit pragma (e.g. vectorize(enable)). If the transformation is explicitly disabled  (e.g. vectorize(disable)), that takes precedence over pragmas implicitly enabling it.

We should warn for obvious conflicts (like your second example), but we probably should not not put too much knowledge about the specific parameters into clang. 


    vectorize(enable) vectorize_width(1)

IMO we should enable the transformation and set vector_width=1 in the metadata. This might not make too much sense (it instructs LoopVectorize to only do interleaving), but I do not think it would be a good idea to add too much logic to validate parameter combinations to clang. We can always provide information via optimization remarks from the transforms.


I agree. The fact that this construct enables interleaving is non-obvious, and that might not be ideal. We do have a separate pragma for that. Nevertheless, we should certainly handle the width = 1 case; in general, the width might be a dependent value (e.g., a non-type template parameter).

 -Hal




Should this enable of disable vectorisation? This is now important when an option implies setting the transformation.  I think it probably makes most sense that enabling/disabling the transformation should take precedence over setting the transformation options, and so in this example vectorisation should be enabled. With this logic, the predicate hint is ignored because vectorisation is disabled in this case:

    vectorize(disable) vectorize_predicate(enable)

IMO it makes sense for the more explicit pragma (vectorize(disable)) to take precedence over the one that implicitly enables vectorization. We should disable vectorization via metadata.


Cheers,
Florian

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev