[LLVMdev] Prevent instruction elimination

Xinfinity xinfinity_a at yahoo.com
Mon Oct 25 12:09:24 PDT 2010



Devang Patel wrote:
> 
> 
> What are you going to do if "optimized LLVM code" is hoisted above or
> sinked below LLVM_dummy_inst by the optimizer ? It seems you are looking
> for a way communicate some info for a block of instructions. If that is
> the case then one solution is to extract interesting block of instructions
> in a separate function and make sure that function is not inlined. If this
> is not feasible than attaching your info with each instructions in
> "optimized LLVM code" block is better than trying to find artificial
> barriers to communicate some info.
> -
> Devang
> 
> 

Indeed, I want to use the metadata as barriers. They are meant to mark the
beginning and the end of the compound statement of the pragma.

#pragma my_pragma{
  code
}

Therefore, I expect that the dummy-instructions will be part of different
basic blocks, and I can determine the set of blocks in "code", inside the
pragma region, from the control flow graph. So, if the instructions are
reordered inside the same basic block, it will not pose any problems. Also,
if both the beginning and the end of the barrier are part of the same block,
it can be handled.

I modify clang in order to insert dummy instructions in the location of the
pragma (in the beginning and the end of the pragma scope). I use a map
(source_location, pragma) and I insert the dummy instruction when this
location is reached in the code generator. It seems difficult to attach the
metadata to the first and the last instruction emitted for the compound
statement, as the "code" inside the pragma region can be anything.

Do you consider it would be a better idea to attach metadata to all
instructions emitted between source_location marking the beginning and the
source_location marking the end of the region?

Thank you,
Alexandra



-- 
View this message in context: http://old.nabble.com/Prevent-instruction-elimination-tp30046067p30051017.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.




More information about the llvm-dev mailing list