On Wed, Oct 23, 2013 at 07:22:20PM +0200, Jakub Jelinek wrote:
> On Tue, Oct 22, 2013 at 08:27:54PM +0400, Sergey Ostanevich wrote:
> > still fails on 403 et al.
>
> Ok, reproduced, unfortunately the pending stmt sequences already pretty much
> assume that they will end up in a single combined bas
still fails on 403 et al.
regrename.c: In function 'regrename_optimize':
regrename.c:200:1: internal compiler error: Segmentation fault
regrename_optimize ()
^
0x96698f crash_signal
../../gcc/toplev.c:335
0x9a2657 ssa_default_def(function*, tree_node*)
../../gcc/tree-dfa.c:310
0x
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:
>> ouch.. html got me!
On Tue, Oct 22, 2013 at 05:16:29PM +0400, Sergey Ostanevich wrote:
> ouch.. html got me!
>
> 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 m
ouch.. html got me!
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 mixed results for passed tests:
400.perlbench +0.25%
401.bzip2 -0.40%
429.mcf
On Fri, Oct 18, 2013 at 05:45:15PM +0400, Sergey Ostanevich wrote:
> 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 ()
> ^
Yea
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*, ...)
On Thu, Oct 17, 2013 at 11:26:56AM +0200, Richard Biener wrote:
> On Wed, 16 Oct 2013, pins...@gmail.com wrote:
>
> >
> > > On Oct 15, 2013, at 5:32 AM, Jakub Jelinek wrote:
> > > Especially on i?86/x86_64 if-conversion pass seems to be often
> > > a pessimization, but the vectorization relies o
On Wed, 16 Oct 2013, pins...@gmail.com wrote:
>
> > On Oct 15, 2013, at 5:32 AM, Jakub Jelinek wrote:
> >
> > Hi!
> >
> > Especially on i?86/x86_64 if-conversion pass seems to be often
> > a pessimization, but the vectorization relies on it and without it we can't
> > vectorize a lot of the lo
> On Oct 15, 2013, at 5:32 AM, Jakub Jelinek wrote:
>
> Hi!
>
> Especially on i?86/x86_64 if-conversion pass seems to be often
> a pessimization, but the vectorization relies on it and without it we can't
> vectorize a lot of the loops.
I think on many other targets it actually helps. I know
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?
Hi!
Especially on i?86/x86_64 if-conversion pass seems to be often
a pessimization, but the vectorization relies on it and without it we can't
vectorize a lot of the loops.
Here is a prototype of a patch that will by default (unless explicit
-ftree-loop-if-convert) only if-convert loops internall
12 matches
Mail list logo
