------- Comment #17 from bjoern dot m dot haase at web dot de 2006-08-17 14:36
-------
I have made a superficial analysis of the issue and would like to discuss at
the end of this post a possible approach for resolving PR4131.
The first observation is, that when one is having a code segment like
/* Start */
#include <complex>
using namespace std;
typedef complex<int> ci;
ci fa [3] = {ci(1,2), ci(-1,-2), ci(-42,+42)};
/* End */
the gimple optimizers will yield a very simple code sequence like
/* Start of gimple code */
void __static_initialization_and_destruction_0(int, int) (__initialize_p,
__priority)
{
<bb 2>:
if (__initialize_p == 1) goto <L0>; else goto <L2>;
<L0>:;
if (__priority == 65535) goto <L1>; else goto <L2>;
<L1>:;
fa[0]._M_real = 1;
fa[0]._M_imag = 2;
fa[1]._M_real = -1;
fa[1]._M_imag = -2;
fa[2]._M_real = -42;
fa[2]._M_imag = 42;
<L2>:;
return;
}
/* End of gimple code */
for the constructor function. Namely, I think that there is hope that one would
grep the most important cases if one would try to replace
some_direct_address_in_data_member = const_immediate_integer;
expressions in the constructors by storing the value in the .data initializers.
Namely, one would be placing the values in the initialization memory region and
one would be deleting the assignment expressions.
If at the end of this process, the constructor function would no longer contain
references to the data structure, "const" qualified VAR_DECL could even be
placed in ".rodata".
Thus, for fixing PR4131 I'd like to suggest to
1.) change the definition of the VAR_DECL so that DECL_INITIAL always points
to a memory region holding initialization data. I.e. also for the case
that we are having constructor code. Initially the memory region would
be initialized to 0.
2.) In order to do this, one would need to replace the tests
"DECL_INITIAL(decl) == error_mark_node" by tests against one of the unused
flags in tree_decl_common that would be assigned a new meaning.
E.g., one might take "decl_flag_0" which seems to be unused so far
for VAR_DECL.?
3.) One would then add a new tree optimiation pass that is located somewhere
close to the end of tree optimization. There one would be looking for
expressions like "static_direct_address = const_immediate_value" like
in the sample gimple code above.
One wold be inserting the values in the DECL_INITIAL(decl) memory region
delete the corresponding expression statements in the constructor function.
After making all the possible replacements, one would be re-visiting the
code of the constructor function.
If within the constructor code more complex references to the VAR_DECL
remain, that could not be removed easily, one would set one second flag
in "tree_decl_common" that states that the VAR_DECL needs to reside in ram,
even if it's a const object.
4.) In "var_asm.c" one would be checking if DECL_INITIAL(decl) is completely
zero. In this case it would go into .bss. If the initialization memory
region is not zero altogether, one would place the object in .data .
If it's a const object without the flag
"needs_to_reside_in_ram_even_if_const" it would be placed into .rodata.
IMO, the most complicated part of it would be the new tree pass 3.).
Namely, one would need to find the approriate branch in
void __static_initialization_and_destruction_0(int, int) (__initialize_p,
__priority);
, look for "direct_address_expression = immediate_integer_value;" type
expression statements that are not residing inside loops or other complicated
structures and delete them if possible.
Then one would be looking if there is any reference to some VAR_DECL remaining
in the FUNCTION_DECL of the constructor function. If there is still a
reference,
one would be setting the "needs_to_reside_in_ram_even_if_const" flag.
Otherwise one would clear it.
I would be willing to start with implementing 1,2 and 4, but I am quite sure
that I would need help for 3.
Bjoern.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
