[LLVMdev] basic block reordeing in memory

[John Criswell]

On 11/20/14, 12:22 PM, Zahra Marj wrote:
>
> Hi.
>
> I would like to change order of code basic blocks "in memory" without 
> changing behavior of code. For finding basic block memory address, I 
> use blockaddress(@function, %block) in .ll file (intermediate 
> representation), but it doesn't work well. I would like to see basic 
> blocks in memory explicitly.
>

I don't think the LLVM IR has a way to express the virtual memory 
address at which a basic block is placed.  The blockaddress feature (if 
I recall correctly) is used at the LLVM IR level to build indirect 
branches for jump tables.

If you want to change the order that basic blocks are placed in memory, 
I think you can simply reorder the basic blocks within the list of basic 
blocks that belong to a function.  The code generator typically 
generates native code for basic blocks in the order in which they appear 
in the function, so if you change the order within the list, they get 
generated in a different order (the control flow between basic blocks 
will not change as each basic block ends with an explicit branch or 
return instruction).

Please note that doing it this way is taking advantage of a side effect 
within the code generator.  Future versions of LLVM can layout the basic 
blocks any way it likes, so while it will probably work today, it may 
not work in the future.

Regards,

John Criswell

> Is changing place of basic blocks in CFG using successors and 
> predecessors helpful?
>
> What parts of LLVM help me and how? I am a newbie on LLVM.
>
> Thanks.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141125/19aeab01/attachment.html>