[LLVMdev] Create superblock in LLVM IR

[Tomas Minac]

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

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>