On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Following up on the recent discussion about GIMPLE tuples
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
our main ideas and implementation proposal in the attached document.
This should be enough to get the implementation going, but there will be
many details that still need to be addressed.
Thoughts/comments on the proposal?
It looks decent, but I also would go one step further with location
information and
PHI node "canonicalization". Further for memory usage we may want to use
available padding on gimple_statement_base as flags or somehow trick gcc to use
tail-padding for inheritance...
For traversal speed I'd also put the chain first in the structure:
struct gimple_statement_base
{
struct gimple_statement_base *next;
/* maybe code and subcode here - that would make it the same
cache-line but does
not allow for tail-padding re-use on 64bit archs. */
struct basic_block_def *bb; /* basic block of stmt is also
frequently accessed */
struct gimple_statement_base *prev;
source_locus locus;
tree block;
unsigned code : 16;
unsigned subcode : 16;
/* if we have padding here a unsigned flags : XX */
}
struct gimple_statement_with_ops
{
struct gimple_statement_base base __attribute__((packed));
unsigned modified : 1;
...
(the packed attribute does not change the size of base though :()
Richard.
