Hi!
I didn't find any precedent of the following before, so this can be a start for
discussion.
Options are known to be different between compilers and achieve options
compatibility is somewhat complex because of this. GCC can be taken as a
reference point, but since other comilers still can (and
Jakub
2013-11-25 Sergey Ostanevich
* c.opt: Introduced a new openmp-simd warning.
* lang.opt: Ditto.
* common.opt: Introduced a new option -fsimd-cost-model.
* doc/invoke.texi: Introduced a new openmp-simd warning and
a new -fsimd-cost-mode
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:
>>
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
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
&& flag_simd_cost_model == VECT_COST_MODEL_UNLIMITED));
}
/* Source location */
On Wed, Nov 20, 2013 at 12:14 AM, Tobias Burnus wrote:
> I have some small comments to the patch:
>
> * You should also update gcc/doc/invoke.texi
>
>
> Sergey Ostanevich wrote:
>
UNLIMITED));
}
/* Source location */
On Tue, Nov 19, 2013 at 6:42 PM, Jakub Jelinek wrote:
> 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
>> > 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
ct_cost_model == VECT_COST_MODEL_UNLIMITED));
}
/* Source location */
On Mon, Nov 18, 2013 at 7:13 PM, Richard Biener wrote:
> 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 ho
:24 PM, Richard Biener wrote:
> 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, %r
pragma omp parallel. Vectorizer cost model is an obstacle
here, not a help.
Regards,
Sergos
On Fri, Nov 15, 2013 at 1:08 AM, Richard Biener wrote:
> Sergey Ostanevich wrote:
>>this is only for the whole file? I mean to have a particular loop
>>vectorized in a
>>file while all
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 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 patc
wrote:
> 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 ca
can be used.
so I believe loop->force_vect is the only trigger to disregard
the cost model
On Tue, Nov 12, 2013 at 4:48 PM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 04:45:17PM +0400, Sergey Ostanevich wrote:
>> yes, ICC ignores cost analysis and follows user request on introductio
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
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
for instructions.
specmake: *** [regrename.o] Error 1
On Tue, Oct 22, 2013 at 6:08 PM, Sergey Ostanevich wrote:
> I use
> -march=core-avx2 -static -Ofast -flto -funroll-loops
> with all 3 patches applied to git version I mentioned
>
> the same is in progress for 'take 3'
&
I use
-march=core-avx2 -static -Ofast -flto -funroll-loops
with all 3 patches applied to git version I mentioned
the same is in progress for 'take 3'
On Tue, Oct 22, 2013 at 5:26 PM, Jakub Jelinek wrote:
> On Tue, Oct 22, 2013 at 05:16:29PM +0400, Sergey Ostanevich wrote:
>>
s
On Tue, Oct 22, 2013 at 5:12 PM, Sergey Ostanevich wrote:
> applying to the same as before
>
> commit 0e3dfadd374c3045a926afa6d06af276cee2108d
> Author: rguenth
> Date: Fri Oct 18 08:36:28 2013 +
>
> trying '06 build.
>
>
> for take 2 on HSW there were
failed on 403 of '06:
regclass.c: In function 'init_reg_sets':
regclass.c:277:1: internal compiler error: tree check: expected
ssa_name, have var_decl in copy_ssa_name_fn, at tree-ssanames.c:393
init_reg_sets ()
^
0xb74124 tree_check_failed(tree_node const*, char const*, int, char const*, ...)
Jakub, Richard,
I believe this patch is a good opportunity to improve the
vectorization capabilities.
I have the following question related to it: whether we plan to treat
the #pragma omp simd as a
directive to vectorize the underlying loop, hence dropping any
assessment regarding profitablity?
On Tue, Apr 17, 2012 at 6:41 PM, Andi Kleen wrote:
>> I also have a question regarding AS compatibility. In case one built
>> GCC using AS with support of HLE then using this GCC on a machine with
>> old AS will cause fail because of usupported prefix. Can we support it
>
> I don't think that's a
>
> Any other inputs?
>
I would suggest to use "snprintf" b/gcc/config/i386/i386-c.c to avoid
possible buffer overrun.
I also have a question regarding AS compatibility. In case one built
GCC using AS with support of HLE then using this GCC on a machine with
old AS will cause fail because of usup
Eric,
I will follow up while Ilya is on vacation.
I can see only one patch along the dicussion so I will use it, making
changes to follow phase renaming and documentation?
I am covered by FSF agreement too, on the same Intel's list as Ilya.
regards,
Sergos
On Fri, Nov 11, 2011 at 2:12 PM, Eric
On Wed, Nov 2, 2011 at 3:42 PM, Richard Guenther wrote:
> On Sat, 29 Oct 2011, Sergey Ostanevich wrote:
>
>> On Fri, Oct 28, 2011 at 7:25 PM, Sergey Ostanevich
>> wrote:
>> > On Fri, Oct 28, 2011 at 4:52 PM, Richard Guenther
>> > wrote:
>> >&
On Fri, Oct 28, 2011 at 7:25 PM, Sergey Ostanevich wrote:
> On Fri, Oct 28, 2011 at 4:52 PM, Richard Guenther wrote:
>> On Fri, 28 Oct 2011, Sergey Ostanevich wrote:
>>
>>> On Fri, Oct 28, 2011 at 12:16 PM, Richard Guenther
>>> wrote:
>>>
On Fri, Oct 28, 2011 at 4:52 PM, Richard Guenther wrote:
> On Fri, 28 Oct 2011, Sergey Ostanevich wrote:
>
>> On Fri, Oct 28, 2011 at 12:16 PM, Richard Guenther wrote:
>> > On Thu, 27 Oct 2011, Uros Bizjak wrote:
>> >
>> >> Hello!
>> >>
&
On Fri, Oct 28, 2011 at 12:16 PM, Richard Guenther wrote:
> On Thu, 27 Oct 2011, Uros Bizjak wrote:
>
>> Hello!
>>
>> > Here's a patch for PR47698, which is about CMOV should not be
>> > generated for memory address marked as volatile.
>> > Successfully bootstrapped and passed make check on
>> >
Hi!
Here's a patch for PR47698, which is about CMOV should not be
generated for memory address marked as volatile.
Successfully bootstrapped and passed make check on x86_64-unknown-linux-gnu.
Is it Ok?
regards,
Sergos
/gcc
2011-10-27 Sergey Ostanevich
PR rtl-optimization/
1,3 +1,8 @@
+2011-10-20 Sergey Ostanevich
+
+ * config/i386/i386.c (processor_target_table): Change Atom
+ align_loops_max_skip to 15.
+
2011-10-17 Michael Spertus
* gcc/c-family/c-common.c (c_common_reswords): Add __bases,
diff --git a/gcc/config/i386/i386.c b/gcc/config/i3
On Wed, Oct 19, 2011 at 4:46 PM, Uros Bizjak wrote:
> On Wed, Oct 19, 2011 at 2:26 PM, Sergey Ostanevich
> wrote:
>
>>> You can just change the default in processor_target_table.
>>>
>>> Uros.
>>>
>>
>> Will it be applicable during optimi
On Wed, Oct 19, 2011 at 4:14 PM, Uros Bizjak wrote:
>
> You can just change the default in processor_target_table.
>
> Uros.
>
Will it be applicable during optimizations for size? It will hurt,
although not much (see PR).
New patch is below. Ok for trunk as obvious?
Sergos
201
Hi!
Here is a patch to address PR50572.
Successfully bootstrapped and passed make check on x86_64-linux.
regards,
Sergos
2011-10-19 Sergey Ostanevich
* gcc/config/i386/i386.c (ix86_option_override_internal): use loop
align by 16 bytes for Atom platform
diff --git a/gcc/config
16.08.2011, в 23:07, Vladimir Makarov написал(а):
> After a lot of thinking and some experiments, I did not find a better
> solution to considerably (like on 0.2% - 0.3% on ARM SPEC2000) improve code
> size than use of non-regional RA for -Os.
>
did you consider change of compile time becau
36 matches
Mail list logo
