https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2006-09-17 22:48:12 |2021-7-25
--- Comment #10 from Andrew Pi
--- 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-loop-arrays's heuristic is way
--- Comment #8 from tbptbp at gmail dot com 2006-09-18 05:52 ---
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-loop-arrays's heuristic is way off the mark" part,
> gcc badly ov
--- Comment #7 from steven at gcc dot gnu dot org 2006-09-18 04:15 ---
To cut down the estimate for the loop size, you need to treat CALL_EXPRs to
machine specific builtins specially (and probably some of the normal builtins
too). See estimate_num_insns_1, the case for CALL_EXPR. You p
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-09-17 22:48 ---
(In reply to comment #4)
> Actually this is just a problem of IV selection, what is happening is the IV
> selection chooses the 1024+(const char *)&base[quad] as the IV instead of just
> &base[quad] which causes the
--- Comment #5 from tbptbp at gmail dot com 2006-09-01 02:53 ---
(In reply to comment #4)
> Actually this is just a problem of IV selection, what is happening is the IV
> selection chooses the 1024+(const char *)&base[quad] as the IV instead of just
> &base[quad] which causes the bigger
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-01 02:46 ---
Actually this is just a problem of IV selection, what is happening is the IV
selection chooses the 1024+(const char *)&base[quad] as the IV instead of just
&base[quad] which causes the bigger encoding.
--
pinskia
