Andrew, There is not any transformation in LLVM that does loop fusion. I do not of anyone who is working on this. If you're interested to work on it then it'd be great! - Devang On Sep 8, 2010, at 9:34 AM, Andrew Clinton wrote:> I did find this note from 2004 that references a LoopFusion pass, but I > can't find it in the source code: > http://nondot.org/sabre/LLVMNotes/LoopOptimizerNotes.txt > > A little background - I'm working on a SIMD runtime, where I have a > scalar program but need to execute it on multiple independent data > elements. One approach is to generate a loop for each operation, then > rely on the optimizer to merge the loops so that I get good locality. > Does this sound like a reasonable approach in LLVM? If you're familiar > with CUDA, I'm after something quite similar where the program is scalar > but the runtime is vectorized. Any pointers in the right direction > would be appreciated! > > Andrew >
On 8 September 2010 18:21, Devang Patel <dpatel at apple.com> wrote:> Andrew, > > There is not any transformation in LLVM that does loop fusion. I do not of anyone who is working on this. If you're interested to work on it then it'd be great!Hi Devang, Do you know if any pass is taking metadata to avoid un-optimizing? Loop fusion can make it worse if you have strong locality (two completely separate big memory access) in terms of cache miss in small-memory platforms. So, would be good if the front-end could pass on some information down the codegen? That could also help implementing union types... I know it's not good to depend on metadata (as for unions), but it could help some architectures to generate better code, rather than just "correct" code. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
On Sep 8, 2010, at 12:13 PM, Renato Golin wrote:> On 8 September 2010 18:21, Devang Patel <dpatel at apple.com> wrote: >> Andrew, >> >> There is not any transformation in LLVM that does loop fusion. I do not of anyone who is working on this. If you're interested to work on it then it'd be great! > > Hi Devang, > > Do you know if any pass is taking metadata to avoid un-optimizing? > Loop fusion can make it worse if you have strong locality (two > completely separate big memory access) in terms of cache miss in > small-memory platforms. So, would be good if the front-end could pass > on some information down the codegen? That could also help > implementing union types... > > I know it's not good to depend on metadata (as for unions), but it > could help some architectures to generate better code, rather than > just "correct" code. >Only thing I know is Dan's recent work on TBAA where FE is using metadata to communicate type info to type based alias analyzer. - Devang
On Sep 8, 2010, at 12:13 PM, Renato Golin wrote:> On 8 September 2010 18:21, Devang Patel <dpatel at apple.com> wrote: >> Andrew, >> >> There is not any transformation in LLVM that does loop fusion. I do not of anyone who is working on this. If you're interested to work on it then it'd be great! > > Hi Devang, > > Do you know if any pass is taking metadata to avoid un-optimizing?Not yet, but it would be valid.> Loop fusion can make it worse if you have strong locality (two > completely separate big memory access) in terms of cache miss in > small-memory platforms.Agreed. And it can compound register pressure and oversubscribe other execution resources. A general-purpose loop fusion pass should consider such things.> So, would be good if the front-end could pass > on some information down the codegen?Perhaps, although most front-ends don't have the kind of information that a loop fusion pass would need, unless you're going to venture into pragma territory.> That could also help > implementing union types...I don't see the connection here.> I know it's not good to depend on metadata (as for unions), but it > could help some architectures to generate better code, rather than > just "correct" code.The main constraint on metadata is that it can't be necessary for correctness. Dan