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

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.


2012/3/29 Andrey Belevantsev<a...@ispras.ru>:

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..),


On 10.02.2012 16:15, Roman Zhuykov wrote:

Ayal, please review this patch and these three patches too:

Roman Zhuykov

Reply via email to