On Wed, Apr 20, 2005 at 06:42:08PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> > Placing variables in a specfic section is only a part of the problem.
>
> I am aware of that. There are already many targets that have special
> handling for section attributes, that result in different code being
> generated when a section attribute is present. Mostly these have to do
> with generating different kinds of address and/or addressing modes
> though, and your case sounds more complicated. Handling different kinds
> of addresses can be done by setting SYMBOL_REF_FLAGS on a symbol_ref.
I also thought about using the SYMBOL_REF_FLAGS, but this would not have
worked for pointers in all cases.
> >My prototype for the m68hc05 does currently the following (based on GCC
> >4.1):
>
> It looks like a reasonable plan.
>
> It relies on MEM_EXPR always being set, which may not be true. But if
> there are places creating MEMs from decls without setting MEM_EXPR, then
> they probably should be fixed. MEMs created for things like spills to
> stack slots may not have MEM_EXPR set, but then they can't possibly have
> the eeprom attribute either, so that is OK.
This not important for my solution, as the conversation is done while
creating the RTL. After the expand pass, the RTL contains library calls,
instead of the writes to the eeprom. RTL based optimiziations should have
no problem with them. I don't think, that an RTL optimizer can even create a
new store expression to the eeprom, if non is present in the RTL (the library
calls are not recognizable as such a expression).
> >+ if (expr == NULL_TREE)
> >+ expr = t;
>
> This is setting MEM_EXPR to a type.
Yes, this may happen, I should change the code. My RTL expander has even
no problem with only a type in MEM_EXPR.
> I see that this does work by accident, because MEM_EXPR can be either a
> decl or a COMPONENT_REF, and all of the code that excludes
> COMPONENT_REFs will also happen to excludes types.
>
> I don't think it is a good idea in general though. Overloading a field
> to have either an expression or a type may result in confusion later.
>
> Presumably this is only a problem because some MEMs don't have the
> MEM_EXPR field set, in which case a better solution is to find the
> places that forget to set it and fix them.
In my test cases, set_mem_attributes_minus_bitpos can be called with eg.
<indirect_ref 0xb7ed82c0
type <integer_type 0xb7f26948 int public HI
size <integer_cst 0xb7ed31f8 constant invariant 16>
unit size <integer_cst 0xb7ed3210 constant invariant 2>
align 8 symtab 0 alias set 2
attributes <tree_list 0xb7f4f840
purpose <identifier_node 0xb7f4cc30 eeprom>> precision 16 min
<integer_cst 0xb7ed3258 -32768> max <integer_cst 0xb7ed3270 32767>
pointer_to_this <pointer_type 0xb7eea6c0>>
arg 0 <plus_expr 0xb7ee81d4
type <pointer_type 0xb7ee96c0 type <integer_type 0xb7f269b4 eint>
public unsigned HI size <integer_cst 0xb7ed31f8 16> unit size
<integer_cst 0xb7ed3210 2>
align 8 symtab 0 alias set -1>
arg 0 <var_decl 0xb7f2506c D.1314 type <pointer_type 0xb7ee96c0>
used unsigned ignored HI file t10.c line 15 size <integer_cst
0xb7ed31f8 16> unit size <integer_cst 0xb7ed3210 2>
align 8 context <function_decl 0xb7f26af8 test>
(reg:HI 27 [ D.1314 ]) chain <var_decl 0xb7f251b0 D.1315>>
arg 1 <integer_cst 0xb7f4f978 constant invariant 20>>>
as t. Such an expression will not be stored in the original code.
Tree based optimizer create in higher optimization levels statements
like *(y+10)=3; which result in this expression.
So, how to change this function? As a MEM_EXPR may only be a DECL or a
COMPONENT_REF,
storing a indriect_ref of a plus_expr is also not valid. This is, why I had to
change
the other functions.
I peronally like to stay for my port at my current solution, until I hit a
problem
or I find a more compilant way for solving this issue. Storing also types has
the advantage, that even in that case, the replacement will work.
If I would change the code to
if(expr ==NULL_TREE&&INDIRECT_REF_P(t))
expr=t;
I could miss some cases (I have mostly worked on RTL level, so I don't know
what other tree expressions are relevant for me).
mfg Martin Kögler
[EMAIL PROTECTED]
