[LLVMdev] Optimization issue for target's offset field of load operation in DAGSelection

[Krzysztof Parzyszek]

On 7/9/2013 12:17 PM, Dan wrote:
> I am working on an experimental target and trying to make sure that
> the load offset field is used to the best way. There appears to be
> some control over the architecture's offset range and whether the
> offset is too large and needs to be lowered/converted into a separate
> sequence of operations in DAGSelection?
>
> Can someone point me to what might be the case?

Instruction patterns can have predicates on each operand to make sure 
that the operand meets the required criteria.  For example, in 
lib/Target/PowerPC/PPCInstrInfo.td, there is a definition of ADDI:

def ADDI   : DForm_2<14, (outs gprc:$rD),
                          (ins gprc_nor0:$rA, symbolLo:$imm),
                      "addi $rD, $rA, $imm", IntSimple,
                      [(set i32:$rD, (add i32:$rA, immSExt16:$imm))]>;

The "immSExt16" is a predicate, and it's defined in the same file:

def immSExt16  : PatLeaf<(imm), [{
   // immSExt16 predicate - True if the immediate fits in a 16-bit
   // sign extended field.  Used by instructions like 'addi'.
   if (N->getValueType(0) == MVT::i32)
     return (int32_t)N->getZExtValue() == (short)N->getZExtValue();
   else
     return (int64_t)N->getZExtValue() == (short)N->getZExtValue();
}]>;


In this case, the ADDI will be generated only if the immediate operand 
satisfies the predicate.  Otherwise, the ADDI pattern won't match, and 
the instruction selector will attempt to match other patterns.  In this 
case it will most likely be the immediate by itself (loaded into a 
register), and then the pattern for ADD (register+register) will match 
on the result.

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation