[LLVMdev] Load serialisation during selection DAG building

Steve Montgomery stephen.montgomery3 at btinternet.com
Mon Aug 13 03:29:18 PDT 2012


I've got a question about how SelectionDAGBuilder treats loads.

The LLVM Language Reference Manual explicitly states that the order of volatile operations may be changed relative to non-volatile operations. However, when the SelectionDAGBuilder in LLVM 3.1 encounters a volatile load, it flushes all pending loads and then chains the volatile load onto them meaning that the volatile load must be scheduled after those loads. While this behaviour isn't wrong, it seems to reduce the scope for efficient instruction selection.

Is there any reason not to modify the behaviour of SelectionDAGBuilder::visitLoad() so that volatile loads don't cause SelectionDAGBuilder::getRoot() to be called. Instead, they can be chained together with the head of the chain being stored in PendingLoads. Then when something else calls SelectionDAGBuilder::getRoot(), the chain of volatile loads is TokenFactored together with the non-volatile loads. I've tried this out and it seems to do what I want but as I'm fairly inexperienced with LLVM, I'm not sure whether there's something else preventing this strategy from working.

The reason I noticed this is because I have been developing a back-end for a target in which some instructions are implemented as pseudos which will be expanded into a pair of instructions. Each of the two operands of the pseudo can be a load but as the expansion accesses the right operand twice, I don't want to match a volatile load for this operand. For example, in:

  %0 = load i16* @y, align 2, !tbaa !0
  %1 = load volatile i16* @x, align 2, !tbaa !0
  %add = add i16 %0, %1 

the volatile load is sequenced after the non-volatile load which means that the non-volatile load can't match the left operand of the add because this would create a scheduling cycle. This means both loads are selected as load instructions, resulting in use of an extra register and an extra instruction. If I change the behaviour of SelectionDAGBuilder::visitLoad() as described then I get just two instructions.



More information about the llvm-dev mailing list