[llvm-commits] [llvm] r66922 - in /llvm/trunk: lib/Target/X86/X86InstrInfo.td test/CodeGen/X86/tls13.ll test/CodeGen/X86/tls14.ll

[Chris Lattner]

On Mar 29, 2009, at 1:22 PM, Rafael Espindola wrote:
>> I'd really like to get here, but I also really like having a flat  
>> list of
>> operands.  I haven't figured out a way to do this without making a  
>> machine
>> operand that is a pointer to a separately allocated "memory operand  
>> thing".
>>  Having them be separately allocated like this is bad for a couple of
>> reasons 1) memory use/allocation cost, 2) traversals of "all  
>> operands" is a
>> tree walk, not a linear scan.  3) locality of the walk is much  
>> less, because
>> it isn't linear walk anymore.
>>
>> I'd really like to fix this somehow though.  Do you have any ideas?
>
> There are some low hanging fruits:
>
> *) Having fewer places is the code that do things like
> ".addImm(foo).addReg(bar).add..."

Stuff that does this should be fixed to use X86InstrBuilder.h, which  
provides abstractions for this.

> *) Having auxiliary functions like getDisplacement and getSegment that
> are given the
> first operand number and just return .getOperand(Num + K)

That makes sense.  Alternatively, maybe a X86::getAddrInfo function  
that returns this as a struct.  This would allow it to be used as:

Seg = X86::getAddrInfo(MI).Seg;

etc.

> If we represent a X86 address with a struct that has just 4 (or 5)  
> pointers we
> could probably still use a liner representation for the  
> instructions, but have
> higher lever access functions that just return a pointer to the  
> middle of the
> instruction?
>
> For example the instruction "movl       %gs:0, %eax" would still have
> 5 (or 6) operands, but could have a higher level method "getSomething"
> that would return the register or the memory position. The register  
> is just
> a regular operand. The memory position has 4 or 5 operands.

Can a helper like getAddrInfo solve this problem without actually  
changing the MachineInstr representation?

-Chris