[LLVMdev] alias information on machine instructions

Florian Brandner fbrandne at mail.tuwien.ac.at
Tue Jul 24 01:09:11 PDT 2007


Dan Gohman wrote:
> I tried out your patch on x86 and it didn't appear to need any special changes.

it might be needed to look at the addressing modes of a load/store to
get the right offset. but i think it should work, if the lowering does
not rewrite loads/stores into custom DAG nodes.

> For the [??], it looks like the IsFrameIndex isn't getting set for the first
> instruction there.

yes, this needs to be added for each target. for our target i've
modified the loadRegFromStackSlot and storeRegToStackSlot methods to add
information on the frame index:
  BuildMI(MB, MBI, TII.get(STORE_REG_IMM)).addReg(framePointer)
      .addFrameIndex(FrameIndex).addReg(SrcReg).addSVOp(FrameIndex);


> I'm curious why you added a new node kind, TargetSrcValue, instead of just
> using the existing SRCVALUE.

this is needed to ensure that the lowering pass does not rewrite them. i
don't know if this is actually done, but anyway i wanted to be on the
safe side.

> 
>> +    else if (MRO.SrcValue && !MRO.SrcValue->getName().empty())
>> +      OS << "[" << MRO.SrcValue->getName() << "]";
> 
> This code should also print the SVOffset value.

this was meant for debugging purpose only, but yes it would be helpful
to print the offset.

this leads to a question on how to query the alias analysis. when i have
a look at the alias set tracker, it seems that only the value and the
size of the type is relevant for the query. but when i look at the
DAGCombiner an "overlap" is calculated from the type size, the offset
and an other offset. how is this supposed to work?

the arguments of the "alias" function are named "V1Size" and "V2Size",
so it would make sense to pass the size only?

> 
>> +  SDOperand getVecLoad(unsigned Count, MVT::ValueType VT, SDOperand Chain, 
>> +                       SDOperand Ptr, SDOperand SV);
> 
> This is code that was deleted from the LLVM trunk recently; it looks like it
> shouldn't be included in this patch.

you are right, sorry.


florian





More information about the llvm-dev mailing list