On Apr 05, 2005 11:55 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> > (IMHO the current RTL IV analysis is not very nice to work
> > with, we could look into improving that first...)
>
> what problems do you have concretely in mind?
It is hard to find and iterate over all IVs (including GIVs).
Hello,
> > Steven Bosscher <[EMAIL PROTECTED]>:
> >
> > >
> > > What happens if you use the memory address unrolling
> > patch, turn on
> > > -fweb, and set the unrolling parameters properly?
> > >
> >
> > The memory address unrolling patch can't work on IA-
> > 64,
>
> Ah, no base+offset. It
On Apr 05, 2005 11:47 AM, Canqun Yang <[EMAIL PROTECTED]> wrote:
> Steven Bosscher <[EMAIL PROTECTED]>:
>
> >
> > What happens if you use the memory address unrolling
> patch, turn on
> > -fweb, and set the unrolling parameters properly?
> >
>
> The memory address unrolling patch can't work on
Steven Bosscher <[EMAIL PROTECTED]>:
>
> What happens if you use the memory address unrolling
patch, turn on
> -fweb, and set the unrolling parameters properly?
>
The memory address unrolling patch can't work on IA-
64, and the -fweb can improve the unroller, but still
far away from the old one
On Tuesday 05 April 2005 09:24, Canqun Yang wrote:
> >On Mon, 28 Mar 2005, James E Wilson wrote:
> >> Steven Bosscher wrote:
> >>> 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 wh
>On Mon, 28 Mar 2005, James E Wilson wrote:
>> Steven Bosscher wrote:
>>> 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?
>> I don't think anyone is objecting to this. [...]
>
On Mon, 28 Mar 2005, James E Wilson wrote:
> Steven Bosscher wrote:
>> 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?
> I don't think anyone is objecting to this. [...]
> I would
Steven Bosscher wrote:
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?
I don't think anyone is objecting to this. My answers in an earlier
thread were a little confused because I didn
ÒýÑÔ Zdenek Dvorak <[EMAIL PROTECTED]>:
> Hello,
>
> > On Sunday 27 March 2005 04:45, Canqun Yang wrote:
> > > Another question is why the new RTL loop-
unroller does
> > > not support giv splitting.
> >
> > Apparently because for most people it is not a
problem that it does
> > not do it, and whi
ÒýÑÔ Zdenek Dvorak <[EMAIL PROTECTED]>:
> Hello,
>
> > On Sunday 27 March 2005 03:53, Canqun Yang wrote:
> > > 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?
> >
> > Almost a
Hello,
> On Sunday 27 March 2005 04:45, Canqun Yang wrote:
> > Another question is why the new RTL loop-unroller does
> > not support giv splitting.
>
> Apparently because for most people it is not a problem that it does
> not do it, and while you have indicated earlier that it may be useful
> fo
Hello,
> On Sunday 27 March 2005 03:53, Canqun Yang wrote:
> > 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?
>
> Almost all of the rtlopt branch was merged. Prefetching is one
>
On Sunday 27 March 2005 04:45, Canqun Yang wrote:
> Another question is why the new RTL loop-unroller does
> not support giv splitting.
Apparently because for most people it is not a problem that it does
not do it, and while you have indicated earlier that it may be useful
for you, you have neithe
ÒýÑÔ Steven Bosscher <[EMAIL PROTECTED]>:
> On Sunday 27 March 2005 03:53, Canqun Yang wrote:
> > 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?
>
> Almost all of the rtlopt branch
On Sunday 27 March 2005 03:53, Canqun Yang wrote:
> 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?
Almost all of the rtlopt branch was merged. Prefetching is one
of the few things that
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 <[EMAIL PROTECTED]>:
> On Saturday 26 March 2005 02:22, Canqun Yang wrote:
> > Â Â Â Â Â Â Â Â * loop.c (PREFETCH_BLO
On Sat, 26 Mar 2005 02:17:58 +0100, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> 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_i
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 n
Hi, all
Currently, GCC just ignores all data prefetches within
loop when the number of prefetches exceeds
SIMULTANEOUS_PREFETCHES. It isn't advisable.
Also, macros defined in ia64.h for data prefetching
are too small.
This patch modified the data prefetch algorithm
defined in loop.c and red
19 matches
Mail list logo
