On Wed, Nov 27, 2013 at 10:58:30AM +0100, Richard Biener wrote:
> On Wed, 27 Nov 2013, Tobias Burnus wrote:
>
> > Am 27.11.2013 08:22, schrieb Sergey Ostanevich:
> > > Done.
> > >
> >
> > Thanks for fixing Richard's and Jakub's comments and parts of mine.
> >
> > > +have the same meaning as des
On Wed, 27 Nov 2013, Tobias Burnus wrote:
> Am 27.11.2013 08:22, schrieb Sergey Ostanevich:
> > Done.
> >
>
> Thanks for fixing Richard's and Jakub's comments and parts of mine.
>
> > +have the same meaning as described in @option{fvect-cost-model} and by
> > +default a cost model defined with
Am 27.11.2013 08:22, schrieb Sergey Ostanevich:
Done.
Thanks for fixing Richard's and Jakub's comments and parts of mine.
+have the same meaning as described in @option{fvect-cost-model} and by
+default a cost model defined with @option{fvect-cost-model} is used.
As mentioned before, pleae a
Done.
Sergos
On Tue, Nov 26, 2013 at 1:46 PM, Jakub Jelinek wrote:
> On Tue, Nov 26, 2013 at 10:43:32AM +0100, Richard Biener wrote:
>> 2013-11-25 sergey.y.ostanevich
>
> Please use your name with capital letters and spaces rather than
> all lowercase plus dots.
>
> Jakub
2013-11-25
On Tue, Nov 26, 2013 at 10:43:32AM +0100, Richard Biener wrote:
> 2013-11-25 sergey.y.ostanevich
Please use your name with capital letters and spaces rather than
all lowercase plus dots.
Jakub
On Mon, 25 Nov 2013, Sergey Ostanevich wrote:
> Updated patch with spaces, etc according to check_GNU_style.sh
>
> Put guard as per Tobias' request.
>
> Is it Ok?
See inline comments below (and Tobias mail).
>
>
> On Thu, Nov 21, 2013 at 6:18 PM, Sergey Ostanevich
> wrote:
> > Tobias,
> >
Sergey,
Thanks for the modifications and the patch. I tried your patch using
gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c with the
following change:
--- a/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmode
Updated patch with spaces, etc according to check_GNU_style.sh
Put guard as per Tobias' request.
Is it Ok?
On Thu, Nov 21, 2013 at 6:18 PM, Sergey Ostanevich wrote:
> Tobias,
>
>
>> When I understand the patch correctly, the warning is shown in two cases:
>> a) When the loop could be vectoriz
Tobias,
> When I understand the patch correctly, the warning is shown in two cases:
> a) When the loop could be vectorized but the cost model prevented it
> b) When the loop couldn't be vectorized because of other reasons (e.g. not
> vectorizable because of conditional loop exits, incomplete vect
First,
Sergey Ostanevich wrote:
+ if (LOOP_VINFO_LOOP (loop_vinfo)->force_vect)
+warning_at (vect_location, OPT_Wopenmp_simd, "vectorization "
+"did not happen for a simd loop");
+
When I understand the patch correctly, the warning is shown in two cases:
a) Whe
Updated as per Richard and Jakub feedback - assuming the default
for simd-cost-model is unlmited by default.
Richard - was you Ok with it?
Sergos
* common.opt: Added new option -fsimd-cost-model.
* tree-vectorizer.h (unlimited_cost_model): Interface update
to rely on parti
On Wed, Nov 20, 2013 at 02:59:21PM +0100, Richard Biener wrote:
> > --- a/gcc/c-family/c.opt
> > +++ b/gcc/c-family/c.opt
> > @@ -592,6 +592,10 @@ Wold-style-definition
> > C ObjC Var(warn_old_style_definition) Warning
> > Warn if an old-style parameter definition is used
> >
> > +Wopenmp-simd
>
On Wed, 20 Nov 2013, Sergey Ostanevich wrote:
> Thanks for comments, hope I got all of em.
> Note: I used a LOOP_VINFO_LOC (loop_vinfo) to print the loop location
> but it appears to be 0, so the output is somewhat lousy. The global
> vect_location points somewhere inside the loop, which is not th
Thanks for comments, hope I got all of em.
Note: I used a LOOP_VINFO_LOC (loop_vinfo) to print the loop location
but it appears to be 0, so the output is somewhat lousy. The global
vect_location points somewhere inside the loop, which is not that better.
Shall we address this separately?
Sergos
I have some small comments to the patch:
* You should also update gcc/doc/invoke.texi
Sergey Ostanevich wrote:
index 0026683..84911a0 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
...
+Wopenmp-simd
+C C++ Var(openmp_simd) Warning
+Warn about omp simd construct is overridden by cost
ok, got it.
I'm not sure if C/C++ and FORTRAN are enough?
* common.opt: Added new option -fsimd-cost-model
* tree-vectorizer.h (unlimited_cost_model): Interface update
to rely on particular loop info
* tree-vect-data-refs.c (vect_peeling_hash_insert): Update to
On Tue, Nov 19, 2013 at 06:39:48PM +0400, Sergey Ostanevich wrote:
> > pedwarn isn't really desirable for this, you want just warning,
> > but some warning you can actually also turn off.
> > -Wopenmp-simd (and we'd use it also when we ignore #pragma omp declare simd
> > because it wasn't useful/de
>> > I propose the following, yet SLP have to use a NULL as a loop info
>> > which looks somewhat hacky.
>>
>> I think this is overengineering. -fvect-cost-model will do as
>> workaround. And -fsimd-vect-cost-model has what I consider
>> duplicate - "simd" and "vect".
>
> I think it is a good ide
On Tue, Nov 19, 2013 at 6:07 PM, Richard Biener wrote:
> On Tue, 19 Nov 2013, Sergey Ostanevich wrote:
>
>> :) agree to you, but as soon as you're a user who tries to introduce
>> vector code and face a bug in cost model you'd like to have a
>> workaround until the bug will be fixed and compiler w
On Tue, Nov 19, 2013 at 03:07:52PM +0100, Richard Biener wrote:
> On Tue, 19 Nov 2013, Sergey Ostanevich wrote:
>
> > :) agree to you, but as soon as you're a user who tries to introduce
> > vector code and face a bug in cost model you'd like to have a
> > workaround until the bug will be fixed an
On Tue, 19 Nov 2013, Sergey Ostanevich wrote:
> :) agree to you, but as soon as you're a user who tries to introduce
> vector code and face a bug in cost model you'd like to have a
> workaround until the bug will be fixed and compiler will come to you
> with new OS distribution, don't you?
>
> I
:) agree to you, but as soon as you're a user who tries to introduce
vector code and face a bug in cost model you'd like to have a
workaround until the bug will be fixed and compiler will come to you
with new OS distribution, don't you?
I propose the following, yet SLP have to use a NULL as a loop
On Mon, 18 Nov 2013, Sergey Ostanevich wrote:
> I would agree that the example is just for the case cost model makes
> correct estimation But how can we assure ourself that it won't have any
> mistakes in the future?
We call it bugs and not mistakes and we have bugzilla for it.
Richard.
> I bel
I would agree that the example is just for the case cost model makes
correct estimation But how can we assure ourself that it won't have any
mistakes in the future?
I believe it'll be Ok to introduce an extra flag as Jakub proposed for the
dedicated simd-forced vectorization to use unlimited cost
On Fri, 15 Nov 2013, Sergey Ostanevich wrote:
> Richard,
>
> here's an example that causes trigger for the cost model.
I hardly believe that (AVX2)
.L9:
vmovups (%rsi), %xmm3
addl$1, %r8d
addq$256, %rsi
vinsertf128 $0x1, -240(%rsi), %ymm3, %ymm1
On Fri, Nov 15, 2013 at 06:06:24PM +0400, Sergey Ostanevich wrote:
> here's an example that causes trigger for the cost model. As soon as
> elemental functions will appear and we update the vectorizer so it can accept
> an elemental function inside the loop - we will have the same
> situation as we
Richard,
here's an example that causes trigger for the cost model. As soon as
elemental functions will appear and we update the vectorizer so it can accept
an elemental function inside the loop - we will have the same
situation as we have
it now: cost model will bail out with profitability estimat
Sergey Ostanevich wrote:
>this is only for the whole file? I mean to have a particular loop
>vectorized in a
>file while all others - up to compiler's cost model. is there such a
>machinery?
No, there is not.
Richard.
>Sergos
>
>On Thu, Nov 14, 2013 at 12:39 PM, Richard Biener
>wrote:
>> On We
this is only for the whole file? I mean to have a particular loop
vectorized in a
file while all others - up to compiler's cost model. is there such a machinery?
Sergos
On Thu, Nov 14, 2013 at 12:39 PM, Richard Biener wrote:
> On Wed, 13 Nov 2013, Sergey Ostanevich wrote:
>
>> I will get some te
On Wed, 13 Nov 2013, Sergey Ostanevich wrote:
> I will get some tests.
> As for cost analysis - simply consider the pragma as a request to
> vectorize. How can I - as a developer - enforce it beyond the pragma?
You can disable the cost model via -fvect-cost-model=unlimited
Richard.
> On Wed, No
I will get some tests.
As for cost analysis - simply consider the pragma as a request to
vectorize. How can I - as a developer - enforce it beyond the pragma?
On Wed, Nov 13, 2013 at 12:55 PM, Richard Biener wrote:
> On Tue, 12 Nov 2013, Sergey Ostanevich wrote:
>
>> The reason patch was in its o
On Tue, 12 Nov 2013, Sergey Ostanevich wrote:
> The reason patch was in its original state is because we want
> to notify user that his assumption of profitability may be wrong.
> This is not a part of any spec and as far as I know ICC does not
> notify user about the case. Still it can be a good
The reason patch was in its original state is because we want
to notify user that his assumption of profitability may be wrong.
This is not a part of any spec and as far as I know ICC does not
notify user about the case. Still it can be a good hint for those
users who tries to get as much as possib
On Tue, Nov 12, 2013 at 03:35:13PM +0100, Richard Biener wrote:
> > Anyway, in that case I think the originally posted patch is wrong,
> > if we want to treat force_vect as disregard all the cost model and
> > force vectorization (well, the name of the field already kind of suggest
> > that), then
On 11/12/13 3:16 PM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 05:46:14PM +0400, Sergey Ostanevich wrote:
>> ivdep just substitutes all cross-iteration data analysis,
>> nothing related to cost model. ICC does not cancel its
>> cost model in case of #pragma ivdep
>>
>> as for the safelen - OMP
On Tue, Nov 12, 2013 at 05:46:14PM +0400, Sergey Ostanevich wrote:
> ivdep just substitutes all cross-iteration data analysis,
> nothing related to cost model. ICC does not cancel its
> cost model in case of #pragma ivdep
>
> as for the safelen - OMP standart treats it as a limitation
> for the ve
ivdep just substitutes all cross-iteration data analysis,
nothing related to cost model. ICC does not cancel its
cost model in case of #pragma ivdep
as for the safelen - OMP standart treats it as a limitation
for the vector length. this means if no safelen is present
an arbitrary vector length can
On Tue, Nov 12, 2013 at 04:45:17PM +0400, Sergey Ostanevich wrote:
> yes, ICC ignores cost analysis and follows user request on introduction of
> simd parallelism in the loop.they follow the omp parallel semantics.
What about #pragma ivdep? I.e. if we decided to follow ICC here, should
we ignore
yes, ICC ignores cost analysis and follows user request on introduction of
simd parallelism in the loop.they follow the omp parallel semantics.
On Tue, Nov 12, 2013 at 3:05 PM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 02:48:46PM +0400, Sergey Ostanevich wrote:
>> You are right regarding the
On Tue, Nov 12, 2013 at 02:48:46PM +0400, Sergey Ostanevich wrote:
> You are right regarding the cost model if we talk about vectorizer alone.
> But the #pragma omp simd goes beyond the vectorizer - it introduces
> parallel context in a place user defines, similar to #pragma omp parallel.
> Are we
Richard, Jakub,
You are right regarding the cost model if we talk about vectorizer alone.
But the #pragma omp simd goes beyond the vectorizer - it introduces
parallel context in a place user defines, similar to #pragma omp parallel.
Are we applying any cost model for omp parallel region?
You can
Jakub Jelinek wrote:
>On Thu, Oct 31, 2013 at 07:02:28PM +0400, Yuri Rumyantsev wrote:
>> Here is a simple fix which allows to vectorize loop marked with
>> 'pragma omp simd' even if cost model tells us that vectorization is
>> not profitable.
>> I checked that on simple test-case is works as expe
On Thu, Oct 31, 2013 at 07:02:28PM +0400, Yuri Rumyantsev wrote:
> Here is a simple fix which allows to vectorize loop marked with
> 'pragma omp simd' even if cost model tells us that vectorization is
> not profitable.
> I checked that on simple test-case is works as expected.
>
> Is it Ok for tru
Hi All,
Here is a simple fix which allows to vectorize loop marked with
'pragma omp simd' even if cost model tells us that vectorization is
not profitable.
I checked that on simple test-case is works as expected.
Is it Ok for trunk?
ChangeLog:
2013-10-31 Yuri Rumyantsev
* tree-vect-loop.c (
44 matches
Mail list logo
