[llvm-commits] [llvm] r66922 - in /llvm/trunk: lib/Target/X86/X86InstrInfo.td test/CodeGen/X86/tls13.ll test/CodeGen/X86/tls14.ll
Chris Lattner
clattner at apple.com
Wed Apr 1 20:11:19 PDT 2009
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
More information about the llvm-commits
mailing list