[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