This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [rtl-optimization] Improve Data Prefetch for IA-64
- From: Steven Bosscher <stevenb at suse dot de>
- To: gcc at gcc dot gnu dot org, Canqun Yang <canqun at nudt dot edu dot cn>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 26 Mar 2005 02:17:58 +0100
- Subject: Re: [rtl-optimization] Improve Data Prefetch for IA-64
- Organization: SUSE Labs
- References: <20050326012212.DCE335B9AC@ds20.nudt.edu.cn>
On Saturday 26 March 2005 02:22, Canqun Yang wrote:
> ÂÂÂÂÂÂÂÂ* loop.c (PREFETCH_BLOCKS_BEFORE_LOOP_MAX): Defined conditionally.
> ÂÂÂÂÂÂÂÂ(scan_loop): Change extra_size from 16 to 128.
> ÂÂÂÂÂÂÂÂ(emit_prefetch_instructions): Don't ignore all prefetches within
> loop.
OK, so I know this is not a popular subject, but can we *please* stop
working on loop.c and focus on getting the new RTL and tree loop passes
to do what we want? All this loop.c patching is a typical example of
why free software development does not always work: always going for
the low-hanging fruit. In this case, there have been several attempts
to replace the prefetching stuff in loop.c with something better. On
the rtl-opt branch there is a new RTL loop-prefetch.c, and on the LNO
branch there is a re-use analysis based prefetching pass. Why don't
you try to finish and improve those passes, instead of making it yet
again harder to remove loop.c. This one file is a *huge* problem for
just about the entire RTL optimizer path. It is, for example, the
reason why there is no profile information available before this old
piece of, if I may say, junk runs, and it the only reason why a great
many functions in for example jump.c and the various cfg*.c files can
still not be removed.
Gr.
Steven