[M3commit] CVS Update: cm3

[Jay K]

 > I think ultimately we should be good gcc citizens and generate proper type information

Me too, but it is a can of worms.
It is hard to get from current situation to typeful situation in small working steps.
I don't have a long attention span, it is difficult to get through large items..


 >  Then we can use properly named symbolic bitfield references
Field/component references. The underlying field will have one of any type: integer, float, pointer, bitfield, etc.
We can use this for records, objects, arrays.

> > Turning it on all the time makes things much slower and I think also actually breaks things (!).
>
> Yikes, really?


It definitely slows things down.
I'm pretty sure when I don't use bitfield refs, I get bad code.
I have to try again.
I don't have things well automated in terms of keeping around various configurations
and easily switching them, and I often go overboard and build too much and don't
do a good job of reducing the problem, but "stare" at too much.


What I should do is like, binary search where the variable is which compiler and
the data being "searched" is, say, all of m3core.


And then once the difference found, have to see why the compiler made the decision.
I haven't debugged the compiler much.
I don't know its domain -- ssa, vdefs, vuses, etc.


> > It complains about the module initializers confusing structs and struct pointers in their return type.
>
> Should be fixable.


Yes. Thing is. I have to test each change both with and without configure enable-checking.
I rely too much on scripts..end up rebuilding backend more than needed (much quicker now
with gmp reduced!)


> Hmm. Do we know what Pascal/Ada/D and friends do in this instance?


Good point. I don't know.
Could be they let gcc use its regular trampolines.
Which has advantages and disadvantages. But I don't know.
(advantages: leaves the work/maintanence to mainline gcc, more interopable with C; disadvantages:
doesn't work on all platforms, is slower (mprotect on some platforms) and faster (no need
to check for the marker)).
But I don't know.
I'd be in favor of transforming this away in the frontend, or maybe in parse.c.
It does require more or less dataflow analysis to see which locals/parameters ared used by nested functions,
which is probably easy to make a safe guess at, but then difficult to make an optimized guess at.
i.e. you'd end up reserving space for and storing locals/parameters that are then not used.


 - Jay

----------------------------------------
> Subject: Re: [M3commit] CVS Update: cm3
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 09:28:05 -0400
> CC: jkrell at elego.de; m3commit at elegosoft.com
> To: jay.krell at cornell.edu
>
> On 6 Oct 2010, at 09:20, Jay K wrote:
>
> > I don't know, but there are many obvious candidates.
> > We don't generate much type information, and we generate now some incorrect type information (wrong level
> > of pointers sometimes on structs)
> > In this case, it was getting a null pointer:
> > edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164
> > if (DECL_STRUCT_FUNCTION (decl))
> >
> >
> > configure -enable-checking still complains about many things. Though I have fixed some.
>
> Yes, this has been most helpful. I would like to push it further but don't currently have the time.
>
> > Turning it on all the time makes things much slower and I think also actually breaks things (!).
>
> Yikes, really?
>
> > It doesn't like the bitfield refs, something about missing a "VUSE".
> > Maybe volatile would be the better tradeoff??
>
> I think ultimately we should be good gcc citizens and generate proper type information. Then we can use properly named symbolic bitfield references. (So long as we can ensure that the front-end and back-end agree on layout.)
>
> > It doesn't like various expressions that mix integer types.
> > These shouldn't be hard to fix, and I have fixed some.
> > They included that we were mixing up the return types of all functions that return
> > integers smaller than a word.
>
> RIght.
>
> > It complains about the module initializers confusing structs and struct pointers in their return type.
>
> Should be fixable.
>
> > However I think not using the bitfield refs generates incorrect code now.
> > ie: when I address configure -enable-checking, I get bad code.
> > I have to look into this more.
>
> Sigh.
>
> > The configure -enable-checking problems seem to be somewhat large and very long standing.
> >
> >
> > Configure -enable-checking also complains something about our use of static chain.
> > It was hard enough just to get the static chain working 4.5...I don't look forward to
> > understanding also figuring out why configure enable-checking doesn't like it.
>
> Hmm. Do we know what Pascal/Ada/D and friends do in this instance?
>
> >
> >
> > - Jay
> >
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Wed, 6 Oct 2010 09:11:00 -0400
> >> To: jkrell at elego.de
> >> CC: m3commit at elegosoft.com
> >> Subject: Re: [M3commit] CVS Update: cm3
> >>
> >> What's wrong with them?
> >>
> >> On 6 Oct 2010, at 11:03, Jay Krell wrote:
> >>
> >>> CVSROOT: /usr/cvs
> >>> Changes by: jkrell at birch. 10/10/06 11:03:54
> >>>
> >>> Modified files:
> >>> cm3/m3-sys/m3cc/gcc/gcc/: ipa.c
> >>>
> >>> Log message:
> >>> neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees
> >>
> >
>