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

[Rafael Espindola]

>> The real solution I can think is to make an instruction like
>>
>> movl       %gs:0, %eax
>>
>> have 2 operands. The first one is the address, the
>> second one is the register. The address is then a C++
>> object with the needed fields.
>>
>> Is there a reason for the current design? Efficiency maybe?
>
> 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..."
*) Having auxiliary functions like getDisplacement and getSegment that
are given the
first operand number and just return .getOperand(Num + K)

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.

> -Chris
>

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047