This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Modulo-scheduling improvements. Patch 2 of 2.
- From: trevor_smigiel at playstation dot sony dot com
- To: Mircea Namolaru <NAMOLARU at il dot ibm dot com>
- Cc: Andrew Pinski <pinskia at gmail dot com>, Andrey Belevantsev <abel at ispras dot ru>, andrew_pinski at playstation dot sony dot com, Ayal Zaks <ZAKS at il dot ibm dot com>, David Edelsohn <dje at watson dot ibm dot com>, Dorit Nuzman <dorit at il dot ibm dot com>, gcc-patches at gcc dot gnu dot org, Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, Vladimir Yanovsky <yanov at il dot ibm dot com>, vmakarov at toronto dot redhat dot com, Vladimir Yanovsky <volodyan at gmail dot com>
- Date: Tue, 10 Jul 2007 18:41:32 -0700
- Subject: Re: [PATCH] Modulo-scheduling improvements. Patch 2 of 2.
- References: <de8d50360706221600k1e897f8cq4892dfb32254a489@mail.gmail.com> <OF677E8DE4.AA4C6C2C-ON42257303.0027E606-42257303.0037E2EA@il.ibm.com>
>
> > If we do add a do_loop_end pattern to the spu back-end in the end, can
> > we then make it dependent it on sms being enabled?
>
> I think that even for SPU the "do-loop" optimization may help.
> When applicable, this transformation transform a sequence
> "increment-compare-branch" to "increment-branch", so a "compare"
> instruction is discarded from a loop. It is true, it may increase
> the reduce pressure as a new induction variable is required. But
> is really the register pressure a problem for SPU ? Maybe we should
> analyze in more depth what causes the degradation mentioned in
> your letter (some tests in which this degradation occurs may be
> very helpful).
Using GCC 4.1.1, one specific case where it performs slightly worse
(~2%) is in the scimark2 benchmark. The doloop_end pattern results in a
new block being created to initialize the new induction variable,
preventing some optimizations later on. Branches are expensive on SPU,
so introducing a new block, potentially effecting branches, is bad.
Register pressure is not the issue.
Other than it enabling SMS, I haven't seen any improvement by using
doloop_end. I think you need to show non-SMS cases where it actually
helps, otherwise, I would only enable it when SMS is enabled. Even that
is not ideal, I'd rather it be done only for loops that are likely to be
optimized by SMS. Of course, not require doloop_end at all is the best
answer, as discussed in other parts of this thread.
Trevor