llvm dev - Jul 2007 - [LLVMdev] alias information on machine instructions

hi,

i know it took a while, but here is a patch that adds a list of source
values to machine instructions.

i modified the DAGISelEmiter to automatically catch regular
loads/stores. custom instructions and loads/stores rewritten by the
lowering pass are not automatically captured.

during the instruction selection a source value operand is added to the
DAG for patterns matching a load/store.

after the scheduling these additional operands are added to the machine
instruction automatically.

one can add special source values for spills, using the machine
instruction builder.

i'm not to happy about the representation of the source values in the
selection DAG. i would like to use a new SelectionDAG node, which
then distinguishes between reads and writes, and adds additional
information on the memory access. but so far the current scheme works fine.

i've testet all this for our backend only, which is not public. i do not
know how much has to be done to integrate this with the other, e.g., the
x86, targets. does any of the other targets rewrite loads/stores during
lowering?

any comments how to integrate this into llvm, and how to proceed to get
the alias analysis working after the codegen prepare pass?

florian


Florian Brandner wrote:
> hi,
> 
> 
> Florian Brandner wrote:
>> Dan Gohman wrote:
>>> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote:
>>>> Right.  The original Value*'s are preserved in the DAG, but
dropped when
>>>> MachineInstrs are created.  We could add a machineoperand to
capture this
>>>> Value* if desired.
>>> Another benefit of keeping the original Value*'s (and offsets)
around is it
>>> would provide more information that could be used for verbose asm
output
>>> and MachineInstr-level dumps, which would be quite nice.
>>>
>> i'll do this and post a patch, unless someone else is already
working on
>> this.
>>
> 
> i have extended the DAG instruction selector and scheduler to preserve
> Value*'s. the values are attached to machine instructions as a separate
> operand list (at least for now). for now this looks very good.
> 
> but i found that the alias analysis is not as good as expected. the
> problem seems to be the codegenprepare pass. GEP instructions are
> lowered to integer calculations (e.g. ptrtoint, add, inttoptr). this
> causes the (basic) alias analysis to answer MayAlias for most queries.
> 
> this is also a problem for the DAG combiner, when the
> -combiner-global-alias-analysis switch is given to llc.
> 
> any ideas how to handle this?
> florian
> 
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Brandner Florian

CD Laboratory - Compilation Techniques for Embedded Processors
Institut für Computersprachen E185/1
Technische Universität Wien

Argentinierstraße 8 / 185
A-1040 Wien, Austria

Tel.: (+431) 58801-58521

E-Mail: brandner at complang.tuwien.ac.at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minstr_svops.patch
Type: text/x-patch
Size: 15517 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070723/a8204901/attachment.bin>

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