[LLVMdev] proof of concept for a loop fusion pass
C Bergström
cbergstrom at pathscale.com
Fri Jan 16 01:40:37 PST 2015
On Fri, Jan 16, 2015 at 4:14 PM, Kristof Beyls <kristof.beyls at arm.com>
wrote:
> Hi Ramshankar,
>
> This looks really interesting.
>
> Interestingly, a patch for loop distribution has been posted for review
> recently.
> On a conceptual level loop fusion and loop distribution are each other’s
> inverse, so I would assume that
> they should ideally somehow be combined and use a single cost function to
> decide, out of all legal
> fusions/distributions, which one is most profitable.
>
> Does that make sense, or is there some reason why these fundamentally
> couldn’t be combined into a single
> loop fuse-and-or-distribute transformation?
>
> I haven’t looked closely at either the code of the distribution or the
> fusion patches, but would it be hard to
> combine them into a single transformation – assuming my assumptions above
> do make sense?
>
> If it would prove sensible to somehow combine the distribution and fusion
> transformations – could this
> be the beginning of a more general high-level loop transformation
> framework in LLVM?
>
At the very high level I don't think the analysis passes should be
combined. Outside of SPEC tuning how would you decide when the cost of
doing one vs the other is appropriate? Without target level information..
how could you estimate the cost or impact? If we think very very long term,
I wonder how something like backtracking could be useful here.. by this I
mean running multiple potentially conflicting or opposing transformations
in parallel, potentially all the way to code generation, and then in the
end pick the path which produces the best output. I realize the
infrastructure to do something like this is almost a dream, but I thought
it's worth mentioning.
If my comments aren't coherent I can potentially dig up the slides from
Fred Chow who originally proposed the idea/concept (for another compiler)
(ping me off list)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150116/ef611b95/attachment.html>
More information about the llvm-dev
mailing list