[LLVMdev] Prevent instruction elimination

John Criswell criswell at illinois.edu
Mon Oct 25 08:14:24 PDT 2010


On 10/25/10 9:49 AM, Xinfinity wrote:
> Hi,
>
>
> John Criswell-4 wrote:
>>
>> You may want to use LLVM Metadata features.  Search for MDNode in the
>> doxygen docs for some information on how to create metadata.
>>
>>
> I use metadata information in this way:
>       unsigned mk = Context.getMDKindID(mdtype);
>       Value  *V = MDString::get(Context,StringRef(str));
>       MDNode* n = MDNode::get(Context,&V, 1);
>       inst->setMetadata(mk, n);
>
> Maybe it is a deprecated way of handling metadata, as I started with this
> code from LLVM 2.6.

I think most of the metadata APIs remained unchanged from LLVM 2.6 to 
LLVM 2.7 (I don't recall making many changes to SAFECode for it).  I 
don't know about LLVM 2.7 to LLVM 2.8.  In any event, I doubt the API 
changes are major.

> But what I need is a dummy instruction ("inst" in the above example), that
> has a minimal impact. I want the code to be optimized (almost) as this
> instruction would not exist.

I'm not familiar with your particular needs, and I'm not an expert on 
annotating LLVM IR either, but it sounds like you just need to use the 
LLVM metadata features.

As for instructions, I don't know of an instruction which does nothing, 
won't be removed by optimization, and yet does not inhibit 
optimization.  Perhaps a local alloca and a volatile load or store would 
do the trick?  Being volatile, the compiler won't remove it (or if it 
does, it's a bug, and you should file a bug report), and since it loads 
from a memory object not used for anything else, alias analysis should 
be able to see that it doesn't interefere with any other load/store.

Other volatile loads/store won't be moved across it, but I doubt that'll 
be a concern.  Most loads/stores are non-volatile.

-- John T.

>
>
> John Criswell-4 wrote:
>>
>> Alternatively, you can use calls to external functions.  These are
>> seldomly optimized since optimizations assume that external functions
>> can have undetermined side effects.
>>
>> -- John T.
>>
>>
> I should avoid calls to some functions, as they would be considered a
> dependence if they are inserted in the body of a loop, and would definitely
> affect the optimization step. I also thought about inserting an inline
> assembly that only contains a comment and carries metadata info. But this is
> also a call, so it influences the optimizers.
>
> Alexandra
>




More information about the llvm-dev mailing list