[LLVMdev] Generating superblocks (SEME regions w/o loops and calls) in LLVM

Sergei Larin slarin at codeaurora.org
Wed Dec 14 07:39:32 PST 2011


It would be very interesting to me to further quality of code scheduling for
our VLIW target.
With very preliminary nature of this discussion I could only say that we
would want to see universal support for a variety of extended BB
representations - EBB, superblock, hyperblock, treegion (though the core of
it would probably be virtually identical).
It should also fit seamlessly into Evan's proposal for bundle representation
(see this thread
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-December/045846.html)

Sergei Larin

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.


> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Alexander Potapenko
> Sent: Wednesday, December 14, 2011 9:22 AM
> To: LLVMdev at cs.uiuc.edu
> Subject: [LLVMdev] Generating superblocks (SEME regions w/o loops and
> calls) in LLVM
> 
> Hi all,
> 
> While developing compile-time instrumentation for ThreadSanitizer
> (http://code.google.com/p/data-race-test) I need to generate SEME
> regions without loop and call instructions
> (I'll call them superblocks hereafter, although some researchers do
> allow loops in their definition of superblocks).
> 
> This is necessary to get the largest piece of IR in which the memory
> operations can be enumerated in order to record the addresses of the
> memory accesses into a fixed-size buffer.
> 
> So far I was using my home-brewed structure to hold the superblocks:
> 
> struct SBlock {
>   BlockSet blocks;
>   llvm::BasicBlock *entry;
>   BlockSet exits;
>   InstSet mops_to_instrument;
>   int num_mops;
>   SBlock() : num_mops(0) {}
> };
> 
> and several functions that split basic blocks to eliminate calls from
> them, traverse the call graph and create the SBlock instances from the
> basic blocks.
> 
> Now I want to simplify my instrumentation pass and move that
> superblock creation logic out of it.
> Is there a strong need to make such a functionality common? Can other
> passes benefit from it?
> 
> There's also the Trace class, which can be used to hold the
> superblocks, but I haven't found any code that generates them at
> compile time (in my case those should not depend on any dynamic
> analysis).
> 
> 
> Thanks in advance,
> Alexander Potapenko
> Software Engineer
> Google Moscow
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list