--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-04-28 17:56 ---
Subject: Re: [4.3 regression] gomp is broken
> Zdenek, does your patch
>
> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01916.html
>
> fix this?
it should.
--
htt
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-04-20 16:09 ---
Subject: Re: Missed invariant out of the loop with conditionals and shifts
> void quantum_cnot(int control, int target, unsigned long *state, int size)
> {
> int i;
>
&g
--- Comment #13 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-26 23:05 ---
Subject: Re: [4.2/4.3 Regression] rtl loop invariant is broken
> Zdenek, what is the size heuristic for anyway? For powerpc, the current
> heuristic tells the compiler not to mo
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-26 18:18 ---
Subject: Re: [4.3 Regression] rtl loop invariant is broken
> > I would agree, if we had RA capable of that (which I am not quite sure
> > whether we do or not, although this
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-26 18:00 ---
Subject: Re: [4.3 Regression] rtl loop invariant is broken
> > I guess the cost of loading zero is cheaper then?
>
> Cheaper than loading 0xDEADBEEF but not cheap enough not to
--- Comment #21 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-08 15:43 ---
Subject: Re: overflow warnings should not be enabled with -Wall
> I think the description doesn't match the real bug, as explained in comment
> #14
> and #18.
>
> And
--- Comment #19 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-07 22:17 ---
Subject: Re: overflow warnings should not be enabled with -Wall
> IIRC there are some cases that are only caught in the 2nd vrp run. It is still
> a possibility if this bug cannot be
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-07 11:02 ---
Subject: Re: bogus array overflow warnings in unrolled loops
> I don't think this is the same testcase. you will get any warning in this
> case,
> because the compiler cannot
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-07 09:38 ---
Subject: Re: bogus array overflow warnings in unreachable code
> But real length of a cannot be greater than 100. I guess VRP could be
> improved
> to derive a value range for
--- Comment #3 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-05 11:49 ---
Subject: Re: unroll/peel loops not aggressive enough
> We don't unroll non-innermost loops at the moment. I don't know if sccp can
> be taught to handle this case (and if it&
--- Comment #23 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-01-09 23:49 ---
Subject: Re: gfortran miscompiled
> So I'm wondering, does:
>
> Doing diffs in .:
> --- ./tree-ssa-address.c.~1~2006-12-22 21:07:11.0 -0800
> +++
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-12-13 20:22 ---
Subject: Re: gcc doesn't unroll nested loops
> Not understanding much in compiler stuff, I tried what you said, namely
> replace
> the loop with
>
> for(
--- Comment #29 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-09 19:41 ---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
> > I would very much like to see it compared with mem-ssa before mem-ssa
> > branch is merged.
> >
>
--- Comment #26 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-09 18:03 ---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
> > Right, but the difference is, In the scheme i propose, you'd never
> > have overlapping live ranges of v
--- Comment #7 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-06 12:33 ---
Subject: Re: Missed constant propagation into loops
> But obviously for real operands, foo () won't clobber them. I.e. the
> following
> also could be optimized but is not:
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-06 12:08 ---
Subject: Re: Missed constant propagation into loops
> > --- Comment #2 from rakdver at gcc dot gnu dot org 2006-11-06 11:51
> > ---
> > > Have you tried
> &
--- Comment #10 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-01 20:26 ---
Subject: Re: Misscompilation of spec2006 gcc
> > > I will work around this problem by teaching PTA about casts from
> > > nonpointers to pointers, which will cause i
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-01 08:05 ---
Subject: Re: Misscompilation of spec2006 gcc
> > --- Comment #3 from rakdver at gcc dot gnu dot org 2006-11-01 00:49
> > ---
> > access_can_touch_variable dete
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-09-21 12:22 ---
Subject: Re: [4.2 Regression] Misscompilation with structs due to new struct
alias
> > > Why do they get different SMT's?
> > Because of this:
> > /* To avoid c
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-09-18 08:44 ---
Subject: Re: IV selection is messed up
> On 17 Sep 2006 22:48:12 -, rakdver at gcc dot gnu dot org
> <[EMAIL PROTECTED]> wrote:
> > Regarding the "-fprefetch-loo
--- Comment #11 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-08-22 08:05 ---
Subject: Re: [4.2 Regression] dwarf2out.c:2160: ICE:
in build_polynomial_chrec, at tree-chrec.h:108
The fix seems OK to me, could you please test and submit it?
> The following fi
--- Comment #24 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-13 09:03 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > > However, ch isn't just copying the loop header; it is also
>
--- Comment #23 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-13 09:00 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > on your real program, how much performance do you gain by hand-rewriting
&
--- Comment #19 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-13 08:01 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > > I-cache.
> > this only matters if this increase in code size will m
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-13 07:58 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > > I-cache.
> > this only matters if this increase in code size will m
--- Comment #11 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-12 23:39 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> I-cache.
this only matters if this increase in code size will make the code go
out
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-12 23:30 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> Zdenek: I don't see how you can say that what we get is optimal code
--- Comment #11 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-06-16 08:15 ---
Subject: Re: [4.2 Regression] segfault in fold_convert with -ftree-vectorize
> You said that you had a fix in predcom, is that fix in your local
> tree, or have you sent a patch
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-06-05 11:04 ---
Subject: Re: [4.2 Regression] tree check failure building FreePOOMA
> Someone who understands SCEV really needs to fix it.
On this particular piece of code SCEV seems to behave just f
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-05-28 14:25 ---
Subject: Re: Reverse loop order for increased efficiency
> --- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 14:10
> ---
> (In reply to comment #3)
> >
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-05-04 14:56 ---
Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a
simple loop
> Wording of 6.5.6/8 and /9 suggests that array objects larger than the maximum
> value that f
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-05-03 19:34 ---
Subject: Re: [4.2 Regression] GCC error: in n_of_executions_at_least, at
tree-ssa-loop-niter.c:1772
The problem in this PR should have been fixed by my yesterday's patch,
does this
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-27 16:02 ---
Subject: Re: -fivopts producing out of bounds array refs
> One thing is, that find_interesting_uses_address () produces bases that look
> like &(&a[0])->s. I.e. they are not
--- Comment #35 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-12 14:20 ---
Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying
> > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248&action=view)
> > Patch to
--- Comment #14 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-10 15:53 ---
Subject: Re: IVs with the same evolution not eliminated
> I wonder if it helps placing this between cunroll and ivopts...
>
> void foo(int n, int m, int stridex, int stridey, int
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-10 10:24 ---
Subject: Re: loop header should also be pulled out of the inner loop too
> > > actually, thinking about it again, it should suffice to teach
> > > invariant_without_guard
--- Comment #13 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-07 12:57 ---
Subject: Re: loop header should also be pulled out of the inner loop too
> I updated the patch for current mainline, but it still has issues for some
> common uses of loops:
>
&
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-05 10:39 ---
Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a
simple loop
> would be much better here. The question is of course, if the programmer
> is allowed to
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-05 10:20 ---
Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a
simple loop
> > > Confirmed. That gives us a testcase at least.
> > >
> > > Now, bac
--- Comment #2 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-05 10:05 ---
Subject: Re: Unable to determine # of iterations for a simple loop
> Confirmed. That gives us a testcase at least.
>
> Now, back to the folding problem of
>
> PTR +- CST
--- Comment #31 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-04 10:20 ---
Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying
> Zdenek: are you using walk_data->interesting_blocks to not visit PHI nodes on
> non-interesting block
--- Comment #10 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-03 17:22 ---
Subject: Re: [4.1 Regression] wrong final value of induction variable
calculated
> > (In reply to comment #6)
> > > I believe c-common.c:pointer_int_sum is wrong in rel
--- Comment #7 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-03-29 09:11 ---
Subject: Re: Number of iterations not know for simple loop
> > I thought if we know that we are looking at the loop header copy condition
> > that
> > we _know_ that the
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-03-29 09:01 ---
Subject: Re: Number of iterations not know for simple loop
> I thought if we know that we are looking at the loop header copy condition
> that
> we _know_ that the loop runs at l
--- Comment #7 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-03-23 11:27 ---
Subject: Re: Segmentation fault on testsuite case gcc.dg/20020425-1.c
> recursive gimplification will of course break at some point here. I remember
> Zdenek rewriting gimplificatio
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-28 00:18 ---
Subject: Re: [4.0 Regression] ICE with const int copied into two different
functions
> Zdenek, does your patch apply to 4.0?
yes, it does.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-24 21:17 ---
Subject: Re: [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in
matmul_i4.c in loop invariant motion
> I'm not sure how to fix this. The debug trace here says it all: W
--- Comment #3 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-16 12:59 ---
Subject: Re: [4.2 Regression] loop-invariant miscompiles openmp.c
> It doesn't need to be marked as trapping.
> If you have
> if (idx <= 20)
> val = p[idx];
> you
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-13 00:41 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c
execution, -O3 -fomit-frame-pointer -funroll-loops
> > > Just for sure -- does not the patch for PR
--- Comment #11 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-12 23:42 ---
Subject: Re: [4.2 Regression] cc0 targets broken; loop-invariants-move code
doesn't handle cc0.
> What kind of invariant insns can we miss if we don't move any cc0 setters?
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-01 08:18 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE on throw code
Hello,
> Zdenek, have you submitted the patch yet for mainline?
no, I was waiting for reactions on my questions, so that I am s
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-01-04 20:55 ---
Subject: Re: cannot determine number of iterations for loops with <=
> Toon posted an updated patch here:
> http://gcc.gnu.org/ml/fortran/2006-01/msg00048.html
>
> (Toon, I
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-01-03 23:29 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied into two
different functions
> rakdver at gcc dot gnu dot org wrote:
> > --- Comment #6 from rakdver at gcc dot gn
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-01-03 23:24 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied into two
different functions
> --- Comment #7 from mark at codesourcery dot com 2006-01-03 23:01 ---
> Subje
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2005-11-14 09:27 ---
Subject: Re: IVs with the same evolution not eliminated
> They can happen due to macro expansion or C++ template inlining.
And do they?
> I wonder if PRE for scalar-evolutions wo
--- Comment #22 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2005-11-11 13:33 ---
Subject: Re: [4.1 regression] elemental.f90 testsuite failure (-fweb)
> Is this a 4.0 regression too?
yes, the C testcase reproduces for me in 4.0 in the same way,
except that -fweb must
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2005-11-09 23:15 ---
Subject: Re: [killloop-branch] code motion of non-invariant expressions with
hard registers.
> --- Comment #6 from dberlin at gcc dot gnu dot org 2005-11-09 22:53
> ---
>
--- Comment #2 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2005-10-25 15:56 ---
Subject: Re: [4.1 Regression] ICE in ivopts
Hello,
> Breakpoint 1, fancy_abort (file=0xb1cc18
> "../../mainline/gcc/tree-ssa-loop-ivopts.c",
> line=2948
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-09-14 12:41 ---
Subject: Re: [4.0 Regression] suboptimal use of fancy x86 addressing modes
> It looks like it is just following existing practice?
yes, I know. The practice is just wrong, tho
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-08-16 10:21 ---
Subject: Re: [4.0 Regression] wrong results at -O on x86
> > Seems like a duplicate of PR22442 to me.
>
> Even if this is a dup, tescase from that bug does not fail on 4.
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-07-12 14:58 ---
Subject: Re: New: scev cprop causes wrong code
> // fork from bug 22230
> // fails with-O1
> // doesn't fail with -O1 -fno-tree-ccp -fno-tree-dominator-opts
&
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-07-07 06:57 ---
Subject: Re: [4.1 Regression] Dominance error after aggressive dead code
elimination (cd_dce)
Hello,
> On Tue, 2005-07-05 at 23:29 -0600, Jeffrey A Law wrote:
> > DCE in a
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-06-25 11:32 ---
Subject: Re: [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0
than 3.3
> --- Additional Comments From steven at gcc dot gnu dot org 2005-06-25
>
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-06-24 16:24 ---
Subject: Re: [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0
than 3.3
> I don't see how the precious register would matter much. But this compare
> wit
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-06-06 15:00 ---
Subject: Re: openssl is slower when compiled with gcc 4.0 than 3.3
> Looks like the culrpit is t
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-06-06 07:30 ---
Subject: Re: openssl is slower when compiled with gcc 4.0 than 3.3
> Could L1 icache blow-out be the reason?
This is not likely with the minimized example.
--
h
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-06-02 08:01 ---
Subject: Re: openssl is slower when compiled with gcc 4.0 than 3.3
The assembler attributed to 4.0 was produced by mainline (or some
patched version of 4.0), wasn't it?
Otherw
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-24 15:06 ---
Subject: Re: poisoned ggc memory used for -ftree-vectorize
> >there are several places in loop opts that are not GGC-safe (in
> >particular the tree nodes refered from loo
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-24 14:24 ---
Subject: Re: poisoned ggc memory used for -ftree-vectorize
> > Is there a rule that ggc_collect should not be called during loop
> optimizations?
>
> I don't kn
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 22:31 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
> > Anyway, moving possibly non-executed const function may cause also
> > other problem
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 22:15 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
> > --- Additional Comments From rakdver at atrey dot karlin dot mff dot
> > cuni
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 22:05 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
> > --- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
>
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:50 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
> const is different from pure, const cannot read from memory.
this is something that have b
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:23 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
> > > > Nevertheless, even if we are very strict with the definition, moving
> >
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:13 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
> > Nevertheless, even if we are very strict with the definition, moving
> > get_type
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 20:01 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
> const
> Many functions do not examine any values except their arguments, and have
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 19:56 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
> > Because do_something does not have to return, therefore
> > get_type2 does not nece
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-19 20:18 ---
Subject: Re: [4.1 Regression] gcc.dg/vect failures
> --- Additional Comments From janis at gcc dot gnu dot org 2005-05-19
> 19:06 ---
> The ICE shows up on powe
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-04-30 07:54 ---
Subject: Re: [PR tree-optimization/21029, RFC] harmful chrec type conversions
Hello,
> Alexandre Oliva wrote:
> >
> > This is not a final patch; if the idea is consid
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-04-11 10:41 ---
Subject: Re: internal compiler error: in spill_failure, at reload1.c:1880
(-fspeculative-prefetching)
Hello,
> the ICE with the testcase from comment #12 reappeared on mainl
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-03-29 21:09 ---
Subject: Re: [4.0/4.1 regression] ivopts produces code that generates
"unaligned access exception"
> > This most likely can be reproduced on ia64 too and oth
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-03-29 20:47 ---
Subject: Re: [4.0/4.1 regression] ivopts produces code that generates
"unaligned access exception"
> This most likely can be reproduced on ia64 too and other
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-02-14 07:03 ---
Subject: Re: [4.0 regression] Wrong loop exit
> (In reply to comment #5)
> > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00657.html
>
> it may be worth noting t
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-02-13 20:11 ---
Subject: Re: [4.0 Regression] LIM is pulling out a pure function even though
there is something which can modify global memory
> That's a pretty useless definition of pure f
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-02-10 11:12 ---
Subject: Re: [4.0 Regression] Poor quality code after loop unrolling.
> In comment #3 Zdenek said "Possibly even better would be to add generation of
> autoincreme
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-02-02 08:38 ---
Subject: Re: [4.0 Regression] Significant compile time increases for sixtrack
with tree LICM and IV optimization
> Any news here? This is one of the more serious compile t
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-27 19:10 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> Another idea: would it be possible to insert the invalidated names
> during the optimization pass instead of invalidating a
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-27 15:00 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> --- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
> 2005-01-27 13:18 ---
> Subject:
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-25 15:54 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> > More seriously -- which of the possibilities? If I have l
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-25 11:29 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> > (*) I hope; scev is a mess of mutualy recursive functions --
> > analyze_scalar_evolution calling number_of_iterat
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-25 11:16 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> > How? If the reference is left in symbolic form, it means that you know
> > nothing about its value, so the only thin
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-25 11:14 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> > Adding the instantiation cache was compile time neutral on no
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-25 01:57 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> >> * tree-data-ref.c (analyze_overlapping_iterations): chrecs that
> >> are equal overlap
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-25 01:52 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> Do remember that this bug is about bad behavior with deeply nested loops
> and we already have other algorithms that are qua
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-25 01:24 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> > Which one? I cannot find anything relevant in changelog.
> >
>
>
> * tree-data-ref.c (analyze_su
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-25 00:49 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> >>>> Uh, symbolic references are or will be used to do data dependence when
> >>>> MEM_REF and ARRAY_
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-25 00:27 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> >>> Other part is that scev tries to be too clever. Without need to
> >>> represent nonaffine induction v
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-24 23:09 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> > Other part is that scev tries to be too clever. Without need to
> > represent nonaffine induction variables (that w
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-24 22:16 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
> > Still there remain some inefficiences within the scev analysis itself.
> >
>
> Zdenek, have you tried to rev
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-01-24 13:20 ---
Subject: Re: [4.0 Regression] Poor quality code after loop unrolling.
> Zdenek, is this still a regression, or are your suggestions from
> comment #12 only enhancements?
I th
1 - 100 of 126 matches
Mail list logo
