Hello Ayal,
First of all, thanks for your feedback. Now to your questions:
On 31.03.2012 3:20, Ayal Zaks wrote:
Roman, Andrey,
Sorry for the delayed response.
It would indeed be good to have SMS apply to more loop patterns, still
within the realm of *countable* loops. SMS was originally designed to
handle doloops, with a specific pattern controlling the loop, easily
identified and separable from the loop's body. The newly proposed
change to support new loop patterns is pretty invasive and sizable,
taking place entirely within modulo-sched.c. The main issue I've been
considering, is whether it would be possible instead to transform the
new loop patterns we want SMS to handle, into doloops (potentially
introducing additional induction variables to feed other uses), and
then feed the resulting loop into SMS as is? In other words, could you
fold it into doloop.c? And if so, will doing so introduce significant
overheads?
Let me perhaps explain better. The patch itself is one core patch (this
thread) adding the new functionality on detecting more complex loop
patterns and the three fixes to SMS found while working on the main patch
(the fixes are in the mails pinged at the very end of this message). The
three fixes are worthwhile to commit separately anyways, they are splitted
up from the main patch for this purpose, so I would suggest to consider
them in any case.
For the main patch, its core is as small as we could get. It stays with
the countable loops as for the cases where we could get overflow behavior
or infinite loops we bail out early. We handle only a case of simple
same-step affine counters. The main reason why we add support to SMS and
not to the doloop pass are is when we do not pipeline a loop newly
transformed to the doloop form, this loop actually slows down on the
platforms not having a true doloop pattern. One has to undo the doloop
form and to get back to the original loop form to avoid this, which seems
rather strange. Also, the separate decrement insn that changes the
induction variable is better be scheduled to get more precise schedule.
And yes, I believe that making an extra induction variable just to have the
control part without uses in the loop core will be unnecessary overhead.
Thus, I believe that if we do want SMS to handle more complex loop, then it
is inevitable that SMS itself would be somewhat more complex. I would
welcome your suggestions to make the patch more clear. One way I see is
that the function for getting the condition of the new loop form can be
moved to the generic RTL loop code given the agreement of other RTL
maintainers. Also, some new helpers can be introduced for handling this
specific loop forms. But it seems that the distinction between
doloop/non-doloop loops has to stay in the code.
Yours,
Andrey
2012/3/29 Andrey Belevantsev<a...@ispras.ru>:
Hello,
I'd like to ping again those SMS patches once we're back to Stage 1.
Ayal, maybe it would remove some burden for you if you'd review the general
SMS functionality of those patches, and we'd ask RTL folks to look at the
pieces related to RTL pattern matching and generation?
It definitely would ... especially in light of the above issue.
Thanks (for your patches, patience, pings..),
Ayal.
Yours,
Andrey
On 10.02.2012 16:15, Roman Zhuykov wrote:
Ping.
Ayal, please review this patch and these three patches too:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00505.html
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00506.html
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01800.html
--
Roman Zhuykov
zhr...@ispras.ru
