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: Canqun Yang <canqun at nudt dot edu dot cn>
- To: Steven Bosscher <stevenb at suse dot de>
- Cc: gcc at gcc dot gnu dot org, Canqun Yang <canqun at nudt dot edu dot cn>,gcc-patches at gcc dot gnu dot org
- Date: Sun, 27 Mar 2005 09:53:43 +0800 (HKT)
- Subject: Re: [rtl-optimization] Improve Data Prefetch for IA-64
- References: <20050326012212.DCE335B9AC@ds20.nudt.edu.cn> <200503260217.58801.stevenb@suse.de>
- Reply-to: Canqun Yang <canqun at nudt dot edu dot cn>
The last ChangeLog of rtlopt-branch was written in
2003. After more than one year, many impovements in
this branch haven't been put into the GCC HEAD. Why?
ÒýÑÔ Steven Bosscher <stevenb@suse.de>:
> 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_instructio>
> ns): 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
>
>
Canqun Yang
Creative Compiler Research Group.
National University of Defense Technology, China.