* RFC: generate TLS address arithmetic for back-end
@ 2004-11-23 20:04 Aldy Hernandez
2004-11-23 21:45 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Aldy Hernandez @ 2004-11-23 20:04 UTC (permalink / raw)
To: gcc, rth, aoliva
Hi folks.
I've been working on adding TLS to the FR-V port. My work is pretty
much complete, but I've (well Alex) found a possible optimization
opportunity.
Currently, the back-end never sees address arithmetic of TLS variables
(ala (plus (symbol_ref) (const_int))), because the middle-end avoids
such RTL creation when the address is not a constant.
Since staticp() return FALSE for any TLS addresses, we never generate
the aforementioned RTL.
Some ports could benefit from getting the above RTL (FRV for instance).
Is there a reason for this restriction, or is something like the patch
below the right approach?
Obviously, the patch below would need some cleanups (the predicate
should go in tree.c, and a hook should be added for back-ends wishing
to override this type of arithmetic).
Comments?
* expr.c (expand_expr): case PLUS_EXPR: Treat TLS address
arithmetic as a constant.
(tree_tls_address_p): New.
Index: expr.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/expr.c,v
retrieving revision 1.500.2.1
diff -c -p -r1.500.2.1 expr.c
*** expr.c 28 Nov 2003 21:12:37 -0000 1.500.2.1
--- expr.c 23 Nov 2004 19:02:22 -0000
*************** expand_operands (tree exp0, tree exp1, r
*** 6204,6209 ****
--- 6204,6219 ----
}
}
+
+ /* Return TRUE if ``t'' is an ADDR_EXPR of a thread-local variable. */
+ bool
+ tree_tls_address_p (tree t)
+ {
+ if (TREE_CODE (t) != ADDR_EXPR)
+ return false;
+ t = TREE_OPERAND (t, 0);
+ return TREE_CODE (t) == VAR_DECL && DECL_THREAD_LOCAL (t);
+ }
\f
/* expand_expr: generate code for computing expression EXP.
An rtx for the computed value is returned. The value is never null.
*************** expand_expr (tree exp, rtx target, enum
*** 7808,7814 ****
else if (TREE_CODE (TREE_OPERAND (exp, 1)) == INTEGER_CST
&& GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_INT
! && TREE_CONSTANT (TREE_OPERAND (exp, 0)))
{
rtx constant_part;
--- 7818,7825 ----
else if (TREE_CODE (TREE_OPERAND (exp, 1)) == INTEGER_CST
&& GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_INT
! && (TREE_CONSTANT (TREE_OPERAND (exp, 0))
! || tree_tls_address_p (TREE_OPERAND (exp, 0))))
{
rtx constant_part;
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: RFC: generate TLS address arithmetic for back-end
2004-11-23 20:04 RFC: generate TLS address arithmetic for back-end Aldy Hernandez
@ 2004-11-23 21:45 ` Richard Henderson
2004-11-24 0:37 ` Aldy Hernandez
2004-11-24 8:49 ` Aldy Hernandez
0 siblings, 2 replies; 6+ messages in thread
From: Richard Henderson @ 2004-11-23 21:45 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: gcc, aoliva
On Tue, Nov 23, 2004 at 03:11:39PM -0400, Aldy Hernandez wrote:
> * expr.c (expand_expr): case PLUS_EXPR: Treat TLS address
> arithmetic as a constant.
> (tree_tls_address_p): New.
A better place to attack this is to arrange for the address of
such variables to be TREE_INVARIANT (if they're not already),
and to change the test there from TREE_CONSTANT.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: generate TLS address arithmetic for back-end
2004-11-23 21:45 ` Richard Henderson
@ 2004-11-24 0:37 ` Aldy Hernandez
2004-11-24 8:49 ` Aldy Hernandez
1 sibling, 0 replies; 6+ messages in thread
From: Aldy Hernandez @ 2004-11-24 0:37 UTC (permalink / raw)
To: Richard Henderson, gcc, aoliva
On Tue, Nov 23, 2004 at 01:21:08PM -0800, Richard Henderson wrote:
> On Tue, Nov 23, 2004 at 03:11:39PM -0400, Aldy Hernandez wrote:
> > * expr.c (expand_expr): case PLUS_EXPR: Treat TLS address
> > arithmetic as a constant.
> > (tree_tls_address_p): New.
>
> A better place to attack this is to arrange for the address of
> such variables to be TREE_INVARIANT (if they're not already),
> and to change the test there from TREE_CONSTANT.
Ok, I'll wait until I have contributed the FRV TLS code to make submit
this patch, as the branch I'm working on does not have TREE_INVARIANT.
Thanks.
Aldy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: generate TLS address arithmetic for back-end
2004-11-23 21:45 ` Richard Henderson
2004-11-24 0:37 ` Aldy Hernandez
@ 2004-11-24 8:49 ` Aldy Hernandez
2004-11-24 9:31 ` Richard Henderson
1 sibling, 1 reply; 6+ messages in thread
From: Aldy Hernandez @ 2004-11-24 8:49 UTC (permalink / raw)
To: Richard Henderson, gcc, aoliva
On Tue, Nov 23, 2004 at 01:21:08PM -0800, Richard Henderson wrote:
> On Tue, Nov 23, 2004 at 03:11:39PM -0400, Aldy Hernandez wrote:
> > * expr.c (expand_expr): case PLUS_EXPR: Treat TLS address
> > arithmetic as a constant.
> > (tree_tls_address_p): New.
>
> A better place to attack this is to arrange for the address of
> such variables to be TREE_INVARIANT (if they're not already),
> and to change the test there from TREE_CONSTANT.
Ah...what the heck; I was bored.
TREE_INVARIANT was not being set for addresses of thread-local variables.
Fixing this oversight fixed the whole she-bang since I've the
gimplifier and friends take an alternate path to generate the arithmetic
I need (and this path already takes into account TREE_INVARIANT).
Is the patch below correct, or do TLS addresses have to be marked
constant as well as invariant?
Also, would you like this functionality on by default or dependent on a
target hook?
Thanks.
Aldy
* tree.c (recompute_tree_invarant_for_addr_expr): The address of a
thread-local variable is invariant.
Index: tree.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.c,v
retrieving revision 1.445
diff -c -p -r1.445 tree.c
*** tree.c 10 Nov 2004 17:34:39 -0000 1.445
--- tree.c 24 Nov 2004 08:20:56 -0000
*************** do { tree _node = (NODE); \
*** 2421,2427 ****
{
if (staticp (node))
;
! else if (decl_function_context (node) == current_function_decl)
tc = false;
else
ti = tc = false;
--- 2421,2429 ----
{
if (staticp (node))
;
! else if (decl_function_context (node) == current_function_decl
! /* Addresses of thread-local variables are invariant. */
! || (TREE_CODE (node) == VAR_DECL && DECL_THREAD_LOCAL (node)))
tc = false;
else
ti = tc = false;
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: RFC: generate TLS address arithmetic for back-end
2004-11-24 8:49 ` Aldy Hernandez
@ 2004-11-24 9:31 ` Richard Henderson
2004-11-24 17:13 ` Aldy Hernandez
0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2004-11-24 9:31 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: gcc, aoliva
On Wed, Nov 24, 2004 at 04:26:41AM -0400, Aldy Hernandez wrote:
> * tree.c (recompute_tree_invarant_for_addr_expr): The address of a
> thread-local variable is invariant.
Ok.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: generate TLS address arithmetic for back-end
2004-11-24 9:31 ` Richard Henderson
@ 2004-11-24 17:13 ` Aldy Hernandez
0 siblings, 0 replies; 6+ messages in thread
From: Aldy Hernandez @ 2004-11-24 17:13 UTC (permalink / raw)
To: Richard Henderson, gcc, aoliva
On Wed, Nov 24, 2004 at 12:40:04AM -0800, Richard Henderson wrote:
> On Wed, Nov 24, 2004 at 04:26:41AM -0400, Aldy Hernandez wrote:
> > * tree.c (recompute_tree_invarant_for_addr_expr): The address of a
> > thread-local variable is invariant.
>
> Ok.
Ok, so no switch needed.
Tests finished on ppc32-linux. Committing to mainline.
Thank you.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-11-24 16:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-23 20:04 RFC: generate TLS address arithmetic for back-end Aldy Hernandez
2004-11-23 21:45 ` Richard Henderson
2004-11-24 0:37 ` Aldy Hernandez
2004-11-24 8:49 ` Aldy Hernandez
2004-11-24 9:31 ` Richard Henderson
2004-11-24 17:13 ` Aldy Hernandez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).