[M3commit] CVS Update: cm3

[Jay K]

I don't know.
tree.h and tree.def are useful.
I suspect the main problem is we generate obviously dubious trees.


For example, let's say you had:


struct { int a,b; } c;
void F()
{
  printf("%d%d\n", c.a, c.b);
}


There is a notion of "component ref" ie. "field ref" in union or struct/record.
This code can be represented in a fairly straightforward typeful highlevel way with gcc trees.


However what parse.c I believe generates is equivalent to either:


printf("%d%d\n", *(int*)(((char*)&c)), , *(int*)(((char*)&c) + 4)


or:

typedef struct { int a:32; } BF1;
typedef struct { int a,b:32; } BF2;



printf("%d%d\n", ((BF1)c).a, , ((BF2)c).b);


As well, historically, c itself might have been to have no fields, but a size:


struct {  } c; // size = 8



That is what set off this whole adventure, as that construct causes
problems specifically on SPARC64, when it tries to figure out how
to pass the struct/record as a parameter. Though I only recently found
a likely easy workaround for that. Parameter types and how they are
passed can be separately specified, presumably letting us always
pass by address.



I speculate that if we made something much closer to "obviously" correct trees,
our problems would go away.


The trees support fairly high level operations. And strong typing.
But we generate fairly low level operations. And weak, incomplete (incorrect?) typing.


 - Jay

----------------------------------------
> Date: Mon, 13 Sep 2010 16:15:09 -0500
> From: rodney_bates at lcwb.coop
> To: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> Is there any documentation that tells what the invariants are on the
> trees gdb can handle? One would hope there would be. Discovering
> such by reading code in something as big as gcc is a very difficult
> and error-prone job. It sounds like you are having to discover them
> by trial-and-error experiments, which is very much the hard way.
>
> One would hope it exists, but then, from sad experiences, not necessarily
> realistically expect so.
>
> Jay Krell wrote:
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/09/13 09:29:51
> >
> > Modified files:
> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
> >
> > Log message:
> > mark all non-bitfield fields as addressable
> > This was part of a not yet very successful attempt at
> > dealing with configure -enable-checking, and its flagging
> > of our heavy use of bitfield refs.
> > Hopefully we get something that isn't as bad as volatile.
> > Hopefully we can remove this addressability actually,
> > though I'll probably add more first (objects, arrays, etc.)
> >
> > Lots of cosmetic/cleanup.
> > o => offset
> > n => name
> > len, n_len => name_length
> > val => value
> > p => proc
> > l => label
> > a, b, c, aren't terrible identifers, but l is particularly
> > onerous due to resembles to 1
> > t => type
> > more to do here
> > some functions have v and val, can't both be value
> > tree *f => out_f, and use local f to avoid repeated derefs
> > tree *v => out_v
> > consolidate all tracing options
> > There is just one variable now, option_trace_all, and
> > all the options increment it. Almost all of the tracing
> > is at level 1, a little is at 2.
> >
> > call one_gap/m3_gap unconditionally and have it do the check
> >
> > some missing spaces on function calls
> > (really I'd just as soon remove them all, but they are
> > fairly consistently present, so I'm following that style)
> >
> > remove the list of optimizations to possibly disable
> > if need be, regain them from where they came
> >
> > tweak the options a little less; ongoing experimentation
> > to reduce them, but some of them require a lot of
> > debugging and fixing
> >
> > work in progress to synthesize field accesses on loads/stores
> >
> >