--- 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__element * {ref-all}) ref_4
--- 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_pointers__element * {ref-all
--- 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 char) -(signed char) ux
--- 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 the vectorized load
--- 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 misaligned indirect-refs
--- 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$8, %rdx
--- 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 preserves
--- 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 causes FAIL: gcc.dg/pr39794
--- 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
analysis
works, but as far as I
--- 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 (i ...)
{
/*A*/ t = a[i];
/*B*/ a[i+1] = t
--- 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:
for (i ...)
{
/*A*/ t = a[i];
/*B
--- 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 does not alias *(p_1 + 1) independent
--- 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 edges
--- 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 status of my
--- 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]
bb1
L1:
s.0 = PHI(0, s.2)
i
--- 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 against
--- 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:
bb 2:
pretmp.11_26 = (int) s_11(D);
ivtmp.25_28 = (long unsigned int) b_inout_5(D
--- 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
verifiedtested form be a good idea?
I think
--- 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 tailcall if the type
--- 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
templatetypename T
gmic
--- 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 variables.
I
--- 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
confused by the two exits of the loop
--- 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 the single
--- 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 do
you
--- 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 for
your
--- 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 reincarnate
--- 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 alternatives
you're
--- 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 occuring
--- 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 speak of loop
--- 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 fully
--- 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 that have
--- 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, shouldn't
--- 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 we set a new
--- 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
--- 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 (when called from
--- 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_gimple_val? I.e
--- 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 at most a QOI issue
--- 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 code to find out
--- 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 the patch
--- 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 do does not prevent
--- 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 don't think ifcvt
--- 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)
One possible solution
--- 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: tree-data-ref.c
--- 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 #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 (reg/f:DI 113
--- 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.
dominance.c contains code (probably
--- 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 REGION
OK
--- 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 us return symbolic
--- 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 mainline. Since I
--- 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 discussed
--- 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 another
--- 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 ppc64 must be something
--- 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 -maltivec does not
rakdver imply -mabi
--- 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 some similar omission
--- 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?
not really; it seems
--- 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 being
--- 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. Revision
--- 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:
OK, I will have a look.
thanks!
Could you
--- 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 != UNKNOWN
--- 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
--- 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 commoning does not work as well
--- 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 does not work as well
--- 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:
http://www.suse.de/~gcctest
--- 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) next
1161
--- 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 thing to do
65 matches
Mail list logo
