Hi Andy, thank you for your respond, On 09/06/12 21:32, Andrew Trick wrote:> > On Sep 4, 2012, at 9:05 AM, Tomas Minac <minac.tomas at gmail.com > <mailto:minac.tomas at gmail.com>> wrote: > >> >> Hello, >> >> I am member of research team on our Faculty of Information Technology >> (university VUT in Brno Czech Republic). We use LLVM for many >> projects and actually we want to create system, which will be able >> compile and profile aplication for VLIW processors in few iterations. >> We want to load profile information in 'opt' part of LLVM and use it >> for create superblocks. Note, when superblocks will be created, we >> want to use llc for our specials backends. > > I suggest looking at the problem upside-down. What optimization do you > need to enable on superblocks, and how will changing the IR help? Any > single predecessor blocks laid out sequentially looks like a > superblock to me. What do you gain by changing the IR? Maybe you can > write a self-contained MachineIR pass that does the optimization you > need, or extend an existing pass. > > -AndyOur backend processor is VLIW, but we want our system to be platform independent. That means, after this project we maybe used it for specials risc processor or other VLIWs. We think superblock can has multiple outputs, so we want to somehow put basic block together and not only these one, which has single predecessor. The basic goal is create superblock by using branch target expansion, loop peeling, loop unrolling (from article http://www.eecs.umich.edu/~mahlke/papers/1993/hwu_jsuper93.pdf) to get as big superblock as it will be possible. After, in llc will be special scheduler and it will work with these superblocks. Finally, we decided to extend basic block class with information (can be simply integer value) to which superblock basic block belongs. Tomas> >> *.ll -> opt -> llc -> *.asm >> | >> profile information >> >> We are thinking about creating superblocks in two ways: >> 1. Simply join basic blocks and branch instrunction in the join >> point replace by some intrinsic instrunction. >> Example: >> define i32 @foo(i32 %a, i32 %b) nounwind uwtable { >> entry: >> ... >> br i1 %cond, label %if.then, label %if.else >> if.then: ; preds = %entry >> ... >> br label %if.end >> if.else: ; preds = %entry >> ... >> br label %if.end >> if.end: ; preds = %if.else, >> %if.then >> ... >> ret i32 %add7 >> It will be transformed to: >> >> define i32 @foo(i32 %a, i32 %b) nounwind uwtable { >> entry: >> ... >> spec.instrinsic.instr.with.label.on.if.else() >> ... >> br label %if.end >> if.else: ; preds = %entry >> ... >> br label %if.end >> if.end: ; preds = %if.else, >> %if.then >> ... >> ret i32 %add7 >> >> 2. Create class named SuperBlock, which will be very similar to >> BasicBlock class and has vector of contained BasicBlocks. Of course, >> in this case, we will have to create MachineSuperBlock class, because >> we want to use llc, how I noted above. Result can looks like that: >> Example: >> define i32 @foo(i32 %a, i32 %b) nounwind uwtable { >> superblock.entry.start: >> entry: >> ... >> br i1 %cond, label %if.then, label %if.else >> if.then: ; preds = %entry >> ... >> br label %if.end >> superblock.entry.end: >> superblock.if.else.start: >> if.else: ; preds = %entry >> ... >> br label %if.end >> >> superblock.if.else.end: >> superblock.if.end.start: >> if.end: ; preds = %if.else, %if.then >> ... >> ret i32 %add7 >> superblock.if.end.end: >> >> What do you think which way will bring less problems for additional >> processing with llc? >> >> I hope and looking for some more advices or any notes to our drafts I >> will be thankfull. >> >> Regards, >> Tomas Minac >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120917/79dd655d/attachment.html>
On Sep 17, 2012, at 9:13 AM, Tomas Minac <minac.tomas at gmail.com> wrote:> Hi Andy, > > thank you for your respond, > > On 09/06/12 21:32, Andrew Trick wrote: >> >> On Sep 4, 2012, at 9:05 AM, Tomas Minac <minac.tomas at gmail.com> wrote: >> >>> >>> Hello, >>> >>> I am member of research team on our Faculty of Information Technology (university VUT in Brno Czech Republic). We use LLVM for many projects and actually we want to create system, which will be able compile and profile aplication for VLIW processors in few iterations. >>> We want to load profile information in 'opt' part of LLVM and use it for create superblocks. Note, when superblocks will be created, we want to use llc for our specials backends. >> >> I suggest looking at the problem upside-down. What optimization do you need to enable on superblocks, and how will changing the IR help? Any single predecessor blocks laid out sequentially looks like a superblock to me. What do you gain by changing the IR? Maybe you can write a self-contained MachineIR pass that does the optimization you need, or extend an existing pass. >> >> -Andy > > Our backend processor is VLIW, but we want our system to be platform independent. That means, after this project we maybe used it for specials risc processor or other VLIWs. > We think superblock can has multiple outputs, so we want to somehow put basic block together and not only these one, which has single predecessor. The basic goal is create superblock by using branch target expansion, loop peeling, loop unrolling (from article http://www.eecs.umich.edu/~mahlke/papers/1993/hwu_jsuper93.pdf) to get as big superblock as it will be possible. After, in llc will be special scheduler and it will work with these superblocks. > Finally, we decided to extend basic block class with information (can be simply integer value) to which superblock basic block belongs.Yes, you need to transform the CFG to form superblocks. No you don't need to extend the IR itself. You can implement a new Analysis pass that summarizes superblocks (e.g. which superblock does each block belong to). Although I'm not sure what that buys you over simply laying out the blocks in superblock order. -Andy>>> *.ll -> opt -> llc -> *.asm >>> | >>> profile information >>> >>> We are thinking about creating superblocks in two ways: >>> 1. Simply join basic blocks and branch instrunction in the join point replace by some intrinsic instrunction. >>> Example: >>> define i32 @foo(i32 %a, i32 %b) nounwind uwtable { >>> entry: >>> ... >>> br i1 %cond, label %if.then, label %if.else >>> if.then: ; preds = %entry >>> ... >>> br label %if.end >>> if.else: ; preds = %entry >>> ... >>> br label %if.end >>> if.end: ; preds = %if.else, %if.then >>> ... >>> ret i32 %add7 >>> It will be transformed to: >>> >>> define i32 @foo(i32 %a, i32 %b) nounwind uwtable { >>> entry: >>> ... >>> spec.instrinsic.instr.with.label.on.if.else() >>> ... >>> br label %if.end >>> if.else: ; preds = %entry >>> ... >>> br label %if.end >>> if.end: ; preds = %if.else, %if.then >>> ... >>> ret i32 %add7 >>> >>> 2. Create class named SuperBlock, which will be very similar to BasicBlock class and has vector of contained BasicBlocks. Of course, in this case, we will have to create MachineSuperBlock class, because we want to use llc, how I noted above. Result can looks like that: >>> Example: >>> define i32 @foo(i32 %a, i32 %b) nounwind uwtable { >>> superblock.entry.start: >>> entry: >>> ... >>> br i1 %cond, label %if.then, label %if.else >>> if.then: ; preds = %entry >>> ... >>> br label %if.end >>> superblock.entry.end: >>> superblock.if.else.start: >>> if.else: ; preds = %entry >>> ... >>> br label %if.end >>> >>> superblock.if.else.end: >>> superblock.if.end.start: >>> if.end: ; preds = %if.else, %if.then >>> ... >>> ret i32 %add7 >>> superblock.if.end.end: >>> >>> What do you think which way will bring less problems for additional processing with llc? >>> >>> I hope and looking for some more advices or any notes to our drafts I will be thankfull. >>> >>> Regards, >>> Tomas Minac >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120917/5f274ce4/attachment.html>
Last time I asked here about superblocks (which we were using in the first version of ThreadSanitizer instrumentation) Tobias Grosser has suggested to use RegionInfo: did you have a look at the RegionInfo pass? It currently detects some kind of refinded SESE regions. I use them in Polly and as far as I know the Intel OpenCL SDK also uses them in some way. It is not SEME, but it may either fit your needs or we may think about extending it. If you want to give it a try you can use: opt -view-regions-only file.ll It would be great if we could have just a single RegionInfo analysis that can then be used by other passes to detect and/or generate the kind of regions they need.