[M3commit] CVS Update: cm3

[Jay K]

ps: configure -enable-checking points out lots of problems, or at least
countless instances of a small number of problems, with our trees.


For example, trees apparently don't support adding any two different
types together, e.g. int8 + int32. But we do it, and it seems to work.


The bitfield refs we generate seem to cause a specific error.
But changing to the other form generates bad code somewhere under -O3.


It also doesn't like something about how we use static chains.


configure -enable-checking never should have gone bad imho.


 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: rodney_bates at lcwb.coop; m3commit at elegosoft.com
> Date: Mon, 13 Sep 2010 23:45:01 +0000
> Subject: Re: [M3commit] CVS Update: cm3
>
>
> 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
> > >
> > >
>