[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 28, 2009, at 1:21 PM, Rafael Espindola wrote:
>> Instead of making it TLS specific, I'd just make that operand  
>> "specify
>> the segment".  Even though we do nothing with FS or ES or DS etc, it
>> would be nice to be able to have a clean model where the instructions
>> think about these machine level things, and isel lowering handles the
>> translation of "TLS to GS"
>
> I have started to work on it, but there lots of places in the code  
> that
> assume that addresses are made of 4 components. I did a bit
> of code factoring, but the real problem is that there no C++
> class that corresponds to an address.

Yes!  Your code factoring has looked great FWIW.

This issue (memory operands being a random target-specific number of  
machine operands is also really annoying for InlineAsm nodes, which  
have to use a machine operand flag before each "logical operand" that  
notes how many machine operands there are for them.  This is really  
gross.

Another annoying detail is that we have no good way to know that some  
unit is a "memory reference" at the machineinstr level (we can  
reference the group of 4 as one operand at the dag level though!).   
For this reason, we can't attach MEMOPERAND information to the  
specific operand, we have to attach it at a random place in the  
operand list.  This is annoying.

> 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?

-Chris