Create superblock in LLVM IR

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.

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

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

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

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.

The superblock formation that Tomas is doing will create lots of single-entry multiple-exit-block regions.
-Andy