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

Rafael Espindola espindola at google.com
Tue Mar 31 15:17:50 PDT 2009


> 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 am having some problem along this path.

I have added a X86::SegmentAddress node and TLS addresses are lowered
into it. This
works perfectly for the case we do a load. Just another recursive call
in MatchAddress
and record the segment.

The problem is when we just want to compute the address as in

int __thread v;
int *f(void)
{
 return &v;
}

In this case, Select is called on the wrapper and it must be expanded
into two instructions. A "mov gs:0, %a_register" to get the thread pointer
and a leal/add to get the address. Is Select really the best place to do
such expansion?

An option that looks better so far is to keep the current THREAD_POINTER
node. The idea is:

1) Lowering produces an add of and offset and the THREAD_POINTER
as it does now.
2) The THREAD_POINTER is selected into a mov gs:0, a_register
3) If we are computing and address, we are done
4) If we are doing a load, the two instructions get folded post the
   instruction selection.

In summary, at the DAG level we will see a THREAD_POINTER and
not addresses with segments. At the machine instruction level we
will see addresses with segments.

I am just not sure if the folding described in 4 will always be done.

comments?

> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>


Cheers,
-- :::
Rafael Avila de Espindola

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




More information about the llvm-commits mailing list