------- 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 bigger encoding.
My guess is that there are two reasons for this:
1) at the moment, ivopts do not know that _mm_prefetch (or __builtin_prefetch
or any other prefetching builtin) is special and that the address it takes may
be expressed using an addressing mode
2) the cost function for addresses pretends that more complicated addressing
modes are cheaper
Both problems can be solved, but most likely not in stage3.
Regarding the "-fprefetch-loop-arrays's heuristic is way off the mark" part,
gcc badly overestimates the size of the loop (it guesses 300 insns). I will
check what I can do with that.
--
rakdver at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2006-09-17 22:48:12
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
