--- Comment #53 from rakdver at kam dot mff dot cuni dot cz 2008-12-10
18:15 ---
Subject: Re: [4.3/4.4 regression] udivdi3 counterproductive, unwarranted use
Hi,
> Re. comment #16:
> Zdenek, do you remember which revision / patch removed the cost check?
rev. 122896
> And
--- Comment #54 from rakdver at kam dot mff dot cuni dot cz 2008-12-10
18:23 ---
Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for
e.g. targets with no native div/mod insns
> Zdenek, it would certainly be helpful to have the original justification
--- Comment #57 from rakdver at kam dot mff dot cuni dot cz 2008-12-10
22:02 ---
Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for
e.g. targets with no native div/mod insns
> I think Zdenek is right in comment #54: We should reincarn
--- Comment #61 from rakdver at kam dot mff dot cuni dot cz 2008-12-11
00:28 ---
Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for
e.g. targets with no native div/mod insns
> Furthermore, if we want to generate the loop instead, are the alternati
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2009-05-15
15:44 ---
Subject: Re: [4.3/4.4/4.5 Regression] Number of iterations analysis wrong
> > > It is number of iteration analysis that gets it wrong (I suppose it might
> > > get
> > > confu
--- Comment #5 from rakdver at kam dot mff dot cuni dot cz 2009-08-07
08:54 ---
Subject: Re: [4.3/4.4/4.5 Regression] No loop counter reversal for simple
loops anymore
> The RTL loop optimizer does this optimization. I had to fix it a couple
> of years ago for unsigned var
--- Comment #9 from rakdver at kam dot mff dot cuni dot cz 2007-07-28
19:27 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> > v0 (and v10 are scratch registers and not saved.
>
> so does it look like a register allocation bug then?
no
--- Comment #14 from rakdver at kam dot mff dot cuni dot cz 2007-07-28
21:11 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> What happens if you add -mabi=altivec to the command line, does it work then?
> If not, then that loop I pointed out is
--- Comment #16 from rakdver at kam dot mff dot cuni dot cz 2007-07-29
06:33 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> >>>>> rakdver at kam dot mff dot cuni dot cz writes:
>
> rakdver> Probably the problem is that -
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2007-07-29
07:16 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> > rakdver> Probably the problem is that -maltivec does not
> > rakdver> imply -mabi=altivec, or som
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-07-30
11:56 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> I've tried to bootstrap with "-mabi=altivec", but it failed with the same
> error:
yes, the problem on pp
--- Comment #23 from rakdver at kam dot mff dot cuni dot cz 2007-08-01
09:55 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> Zdenek, do you have the access to a ppc64 machine to work on the bootstrap
> problem?
I do; however, I got stuck with a
--- Comment #26 from rakdver at kam dot mff dot cuni dot cz 2007-08-13
11:31 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> Yesterday, I've tried to check if mainline passes boostrap with vectorization
> enabled on ppc32 using latest mainlin
--- Comment #29 from rakdver at kam dot mff dot cuni dot cz 2007-08-13
18:04 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> --- Comment #27 from victork at il dot ibm dot com 2007-08-13 15:09
> ---
> > this is the problem we discu
--- Comment #3 from rakdver at kam dot mff dot cuni dot cz 2007-08-20
12:10 ---
Subject: Re: Failing to represent the stride (with array) of a dataref when it
is not a constant
> --- Comment #2 from dorit at gcc dot gnu dot org 2007-08-20 05:55 ---
> > Making
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-08-30
18:09 ---
Subject: Re: failing rtl iv analysis (maybe due to df)
> The only thing that you are allowed to do with the DF_REF_ID is to get
> it from a df_def
> AFTER YOU ARE SURE THAT THE DEF IS IN THE R
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-09-05
14:30 ---
Subject: Re: dead-store not eliminated
> > > Ah, I only found add_noreturn_fake_exit_edges which obviously didn't help.
> > > connect_infinite_loops_to_exit does. Thx.
> >
--- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2007-09-16
22:07 ---
Subject: Re: [4.3 Regression] gfortran.dg/g77/19990826-3.f fails at -O1
> What happens in this testcase is (mis)behaviour of invariant code motion.
> On instruction:
> (set (mem/c/i:SI (plus:DI
--- Comment #33 from rakdver at kam dot mff dot cuni dot cz 2007-10-09
12:48 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> Zdenek, do you need an access to PPC, in order to look into this?
I was finally able to get access to the machine I left back
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2007-10-15
15:02 ---
Subject: Re: [4.3 Regression] ICE when compilling elbg.c from ffmpeg
(vectorizer)
> This patch fixes the ICE and doesn't cause regressions in the vectorizer
> testsuite:
>
> Index
--- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2008-02-13
04:05 ---
Subject: Re: [4.3 regression] Unable to coalesce ab SSA_NAMEs
> Actually it is the call to rewrite_into_loop_closed_ssa inserting these
> PHIs. I don't know if it actually makes sense to sp
--- Comment #9 from rakdver at kam dot mff dot cuni dot cz 2008-02-15
14:06 ---
Subject: Re: [4.3 regression] Unable to coalesce ab SSA_NAMEs
> Yeah, forwprop checks that it may propagate the name SR.40_22, but it doesn't
> check recursively if any of the names occu
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2009-02-12
18:29 ---
Subject: Re: Code that compiles fine in 1GB of memory with 4.1.2 requires >
20GB in 4.2.* and higher
> Zdenek, in this case (and PR26854) can we make sure not to recognize loops
> that involve t
--- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2009-02-18
04:11 ---
Subject: Re: loop number of iterations analysis not working
> If the program terminates before i would wrap, then the number of
> iterations was not MAXINT.
> And since it can't wrap, it i
--- Comment #12 from rakdver at kam dot mff dot cuni dot cz 2009-02-25
22:41 ---
Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
> --- Comment #11 from hjl dot tools at gmail dot com 2009-02-25 19:18
> ---
> (In reply to comment #10)
> > The dif
--- Comment #5 from rakdver at kam dot mff dot cuni dot cz 2007-05-07
09:38 ---
Subject: Re: [4.2/4.3 Regression] Code size regression caused by fix to PR
31360
> (In reply to comment #2)
> > > 1) Hoists a register containing 0 out of the loop
> > The correct thin
--- Comment #6 from rakdver at kam dot mff dot cuni dot cz 2007-05-10
09:42 ---
Subject: Re: [4.3 regression] Invalid loop optimization causes bootstrap
failure in genautomata
> Now, imagine the representative of a class of invariant insns is this one:
>
> (gdb) ne
--- Comment #15 from rakdver at kam dot mff dot cuni dot cz 2007-06-02
07:49 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
> > Has anyone measured impact of adding DCE on SPEC CPU 2000/2006 peformance?
>
> Take a look at:
> htt
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-06-04
22:15 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
> Can anyone show that the newly added dce_loop anything useful?
Yes, predictive commoning does not work as well if th
--- Comment #22 from rakdver at kam dot mff dot cuni dot cz 2007-06-04
22:39 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
> > > Can anyone show that the newly added dce_loop anything useful?
> >
> > Yes, predictive commo
--- Comment #24 from rakdver at kam dot mff dot cuni dot cz 2007-06-04
23:23 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
> > > Can anyone show that the newly added dce_loop anything useful?
> >
> > Yes, predictive commoning
--- Comment #1 from rakdver at kam dot mff dot cuni dot cz 2007-06-19
22:07 ---
Subject: Re: New: assertion failure in loop-iv.c; probable dataflow
regression
> The failing assertion in get_biv_step() is:
>
> gcc_assert ((*inner_mode == *outer_mode) != (*extend !
--- Comment #1 from rakdver at kam dot mff dot cuni dot cz 2007-07-02
10:06 ---
Subject: Re: New: Bootstrap with vectorization enabled fails with ICE on PPC
> Since revision 124727, mainline doesn't pass bootstrap wirh vectorization
> enabled on ppc. It works OK on x86
--- Comment #5 from rakdver at kam dot mff dot cuni dot cz 2007-07-02
15:27 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> "rakdver at gcc dot gnu dot org" <[EMAIL PROTECTED]> wrote on
> 02.07.2007 14:51:35:
>
> > O
--- Comment #11 from rakdver at kam dot mff dot cuni dot cz 2010-02-09
08:30 ---
Subject: Re: [4.3/4.4/4.5 Regression] No loop
counter reversal for simple loops anymore
Hi,
> As suggested by Zdenek, here is a patch that lowers the cost of the IV when
> it is compared a
--- Comment #2 from rakdver at kam dot mff dot cuni dot cz 2010-03-03
09:21 ---
Subject: Re: Teaching SCEV about ADDR_EXPR
causes regression
> This together with the patch mentioned in the previous comment allows to
> generate:
> ivtmp.0 = &a[0][0]
>
> L1:
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-01-03
19:37 ---
Subject: Re: Slow compile and much memory use
at -O1
> --- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-03 17:03
> ---
> Well, obviously it is because
>
>
--- Comment #12 from rakdver at kam dot mff dot cuni dot cz 2010-01-16
13:24 ---
Subject: Re: [4.5 Regression] -O2 and verify_stmts
failed again
> > --- Comment #10 from rakdver at gcc dot gnu dot org 2010-01-16 12:53
> > ---
> > /* Reject a ta
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-01-30
09:47 ---
Subject: Re: [4.3/4.4/4.5 regression] extra
spills due to RTL LICM
> (Looking at Zdenek:) Would something like this in a more polished and actually
> verified&tested form be a good idea
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2010-02-05
13:58 ---
Subject: Re: Inefficient loop unrolling
> But if I adjust the cost to make
> "index" cost only 1 or 2, I get this:
>
> :
> pretmp.11_26 = (int) s_11(D);
> ivtm
--- Comment #2 from rakdver at kam dot mff dot cuni dot cz 2010-07-15
17:44 ---
Subject: Re: over-prefetched for arrays of
complex number
> This is a piece of code that shows the two prefetches for b.
>
> mulss %xmm4, %xmm5
> addq
--- Comment #3 from rakdver at kam dot mff dot cuni dot cz 2010-07-22
21:17 ---
Subject: Re: No prefetch for the vectorized
loop
> --- Comment #2 from changpeng dot fang at amd dot com 2010-07-22 20:52
> ---
> (In reply to comment #1)
> > The misa
--- Comment #3 from rakdver at kam dot mff dot cuni dot cz 2010-07-24
20:41 ---
Subject: Re: Redundant prefetches for some
loops (vectorizer produced ones too)
> > The direct reason is that prefetching could not differentiate the base
> > addresses
> > of t
--- Comment #10 from rakdver at kam dot mff dot cuni dot cz 2010-07-27
23:09 ---
Subject: Re: [4.3/4.4/4.5/4.6 Regression]
"safe" conversion from unsigned to signed char gives broken code
> > ux = (unsigned char) x;
> > uy = (unsigned c
--- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
16:33 ---
Subject: Re: New: Number of iteration
analysis bogus
> when looking at the exit 6->7 number_of_iterations_ne is present with
> iv->base (cxb3014__test_block__char_pointers__elemen
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
18:47 ---
Subject: Re: Number of iteration analysis
bogus
> > > when looking at the exit 6->7 number_of_iterations_ne is present with
> > > iv->base (cxb3014__test_block__char_poin
--- Comment #18 from rakdver at kam dot mff dot cuni dot cz 2010-06-07
20:24 ---
Subject: Re: Big spec cpu2006 prefetch regressions
on gcc 4.6 on x86
> --- Comment #14 from changpeng dot fang at amd dot com 2010-06-07 18:27
> ---
> Here is the current sta
--- Comment #15 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
09:37 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
> --- Comment #14 from rguenth at gcc dot gnu dot org 2010-07-07 09:01
> ---
> Huh. Unrolling
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
10:09 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
> (In reply to comment #15)
> > Subject: Re: [4.6 regression] RTL loop
> > unrolling caus
--- Comment #19 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
10:35 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
> > > > I am not sure what you mean -- I may be misunderstanding how rtl alias
> > > > ana
--- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
10:47 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
> > > > > Consider this simplified example:
> > > > >
> > > > > for (
--- Comment #23 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
10:51 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
> > > > > > > Consider this simplified example:
> > >
--- Comment #26 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
11:19 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
> In
>
>...
>*p_1 = x;
>y = *(p_1 + 1);
>...
>
> I can say that *p_1
--- Comment #27 from rakdver at kam dot mff dot cuni dot cz 2010-07-07
11:31 ---
Subject: Re: [4.6 regression] RTL loop
unrolling causes FAIL: gcc.dg/pr39794.c
> Due to SSA form the alias information reflects dependencies only between
> accesses as if it ignores back
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-11-08
14:46 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use
> --- Comment #19 from manu at gcc dot gnu dot org 2007-11-08 14:22 ---
> (In reply to comment #16)
> >
--- Comment #6 from rakdver at kam dot mff dot cuni dot cz 2007-11-20
13:56 ---
Subject: Re: [4.3 Regression] ICE in is_hidden_global_store, at
tree-ssa-sink.c:207
>
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-20 09:13
> ---
> Well I do
--- Comment #22 from rakdver at kam dot mff dot cuni dot cz 2007-11-24
21:52 ---
Subject: Re: [4.3 Regression] Code size regression caused by fix to PR 31360
> > Why? If using dec and branch is profitable, doloop pass should do it; the
> > transformation that ivopts
--- Comment #27 from rakdver at kam dot mff dot cuni dot cz 2007-11-26
01:12 ---
Subject: Re: [4.3 Regression] Code size regression caused by fix to PR 31360
> Zdenek, do you have the ability to get code-size measurements on ARM? (You
> don't need to actually run the c
--- Comment #29 from rakdver at kam dot mff dot cuni dot cz 2007-11-26
01:42 ---
Subject: Re: [4.3 Regression] Code size regression caused by fix to PR 31360
> --- Comment #28 from pinskia at gcc dot gnu dot org 2007-11-26 01:24
> ---
> A couple of comments about
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
15:04 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
> --- Comment #6 from jakub at gcc dot gnu dot org 2007-11-27 14:17 ---
> I've changed that
&g
--- Comment #9 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
16:03 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
> > I think the problems only appeared if allow_rhs_cond_expr was enabled
> > for the gimplification pass
--- Comment #11 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
16:44 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
> And for 2nd and 3rd argument wouldn't it for loop and vectorizer be sufficient
> to just test is_gimpl
--- Comment #33 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
19:42 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use
> > --- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43
> > ---
> > This is IMHO a
--- Comment #13 from rakdver at kam dot mff dot cuni dot cz 2007-11-28
13:45 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
> --- Comment #12 from jakub at gcc dot gnu dot org 2007-11-28 13:20
> ---
> So, shou
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-11-28
16:05 ---
Subject: Re: [4.3 Regression] VRP/SCEV miscompiles Firefox
> --- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-28 15:47
> ---
> We could clear the SCEV cache for an SSA_NAME
--- Comment #16 from rakdver at kam dot mff dot cuni dot cz 2007-12-05
16:42 ---
Subject: Re: Missed induction variable optimization
> Please correct me if I am wrong, but I think that optimizing out the variable
> that holds number of iterations is not desirable on targets tha
--- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2008-01-11
04:44 ---
Subject: Re: [4.2/4.3 regression] loop performance regression
> Is the testcase gcc.dg/tree-ssa/loop-19.c supposed to work with -fpic/-fPIC?
not necessarily; with -fpic, both memory accesses are fu
67 matches
Mail list logo
