Re: Passing attributes to RTX

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

On Mon, Nov 10, 2008 at 03:40:13PM -0500, Gobaan_Raveendran@amis.com wrote:
> 
> Hello all,
> 
> While prototyping a port of gcc I think that the RTX is lacking some
> information needed to generate machine dependent files. The expression
> trees have the correct information and I can likely hack in a quick fix to
> pass that information down to the backend. However, I just want to make
> sure I am not doing something completely wrong.
> 
> Basically given the following code,
> 
> void main(T x)
> {
>   T * pt; //pointer to type T
>   *pt = x
> }
> 
> now I need the RTX to know about type T (specifically its qualifiers as I
> am doing this for the named address space branch), I changed the backend to
> encode these into the RTX generated by the VAR_DECL and PARM_DECL nodes,
> however, I am not sure if it is suppose to be encoded in the INDIRECT_REF
> node as pt is theoretically a pointer to T.
> 
> I just quickly hacked this information into expand_expr_real_1 in expr.c,
> however this may be the incorrect approach, is there any specific location
> where I should be modifying RTX attributes and when expand_expr_real_1 is
> done should the RTX returned have all the attributes (that can be deduced
> from the expression tree) set?

I am picking up the named address patches from Ben Elliston, and trying to make
them acceptable for inclusion in the 4.5 GCC.  I wasn't aware that anybody
outside of Ben and I were using the branch.

What you discovered is in fact a bug, and I just started looking into it.
Thanks for alterting me to the fact that it doesn't completely work at
present.  I suspect it is a recent regression, and it shouldn't be too hard to
get going again, maybe even some of my recent cleanups caused it.

On the spu, I discovered that it works as intended for -O2, but does not work
at -O and no optimization levels.  For example on the spu, this program:

#include <spu_intrinsics.h>

vec_float4 get (__ea vec_float4 *ptr)
{
  return *ptr;
}

Generates the code at -O2 which shows that the cache functions are being called
to move the data to/from the host address space:

	.file	"foo2.c"
	.global	__cache_fetch
	.text
	.align	3
	.global	get
	.type	get, @function
get:
	ila	$17,__cache_tag_array_size-128
	stqd	$lr,16($sp)
	ila	$16,__cache_tag_array
	stqd	$sp,-32($sp)
	and	$15,$3,$17
	ila	$14,66051
	a	$12,$16,$15
	lqx	$7,$16,$15
	andi	$2,$3,127
	shufb	$11,$3,$3,$14
	ai	$sp,$sp,-32
	lqd	$8,32($12)
	andi	$10,$11,-128
	ceq	$9,$10,$7
	gbb	$5,$9
	clz	$6,$5
	nop	127
	rotqby	$4,$8,$6
	a	$4,$4,$2
	lnop
	brz	$5,.L6
	lnop
.L3:
	ai	$sp,$sp,32
	lqd	$3,0($4)
	nop	127
	lqd	$lr,16($sp)
	bi	$lr
.L6:
	brsl	$lr,__cache_fetch
	ori	$4,$3,0
	br	.L3
	.size	get, .-get
	.ident	"GCC: (GNU) 4.4.0 20081104 (experimental)"


But if I compile it at -O1, it doesn't set up the appropriate fields and just
does a simple load:

	.file	"foo2.c"
	.text
	.align	3
	.global	get
	.type	get, @function
get:
	lqd	$3,0($3)
	bi	$lr
	.size	get, .-get
	.ident	"GCC: (GNU) 4.4.0 20081104 (experimental)"

In terms of the RTL level, the MEM_ADDR_SPACE macro is the accessor that gives
you the address space for that particular memory reference.  Zero is the
default address space, and 1-254 are available for other uses.  Here is the
declaration from rtl.h:

/* For a MEM rtx, the address space.  If 0, the MEM belongs to the
   generic address space.  */
#define MEM_ADDR_SPACE(RTX) (MEM_ATTRS (RTX) == 0 ? 0 : MEM_ATTRS (RTX)->addrspace)

Similarly, at the tree level the TYPE_ADDR_SPACE macro is the accessor macro
for the type node.  Here is the declaration from tree.h:

/* If nonzero, this type is in the extended address space.  */
#define TYPE_ADDR_SPACE(NODE) (TYPE_CHECK (NODE)->type.address_space)

Out of curiosity, could you email me a short summary of how you plan to use the
named address space support in your port?

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com