On Mon, Nov 10, 2008 at 03:40:13PM -0500, [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
