[LLVMdev] [PATCH] Split LoopUnroll pass into mechanism and policy

Matthijs Kooijman matthijs at stdin.nl
Wed May 7 01:08:24 PDT 2008


Hi Dan,

> This should still make it easy to write new unrolling passes with
> custom heuristics, but it would also be more flexible for passes to
> do unrolling in combination with other transformations.
Agreed.

To shed some light on my specific requirements, I am working with an
architecture that has only limited support for loops and control flow. This
means that loop unrolling is not a matter of performance, but any loop that
can't be mapped on the architecture must be unrolled to be able to work. So,
I don't really need the added flexibility, though I agree that it is a good
idea nonetheless.


Splitting off the second part of unrollLoop (the actual unrolling, after
deciding to unroll the loop) shouldn't be a problem. I am a bit concerned
about the first part (before the decision), which finds out the trip count and
trip multiple. Since both policy and mechanism need these values, that code
must be shared somehow as well. I see two options for that:
 1. Put two methods in the utility class, each of which return one of those
    values.
 2. Add two methods to the Loop class. Currently, there is a getTripCount()
    method that returns the trip count as a Value*. Perhaps we could add a
		getTripCountConst() (or getTripCountInt() ?) and getTripCountMultiple() to
		Loop?

It seems to me the second option is nicer, though it shouldn't make too much
of a difference.

Furthermore, where to put this utility class? lib/Transforms/UnrollLoop.cpp
seems reasonable?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080507/e886c3b4/attachment.sig>


More information about the llvm-dev mailing list