Re: Removing ARCNET stuffs

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Jun 01, 2015 at 02:41:22PM -0400, Andrew Cagney wrote:
 > > > To my mind, and I'm assuming a pure SSA compiler design, having SSA
 > > > forces issues like: [...]
 > >
 > > I'm missing something; SSA is just a style of program representation.
 > 
 > Yes.  Lets think of Static Single Assignment as the pure academic theory.

Ok... although calling it a "theory" is a bit much? It's just a scheme
for laying out program representations. A useful one for various
reasons; but it's not itself a representation and it doesn't have much
effect on the rest of the architecture of the compiler backend, except
maybe for naive backends.

Or so it seems to me anyway, but I've been up to my ears in compiler
hokum in connection with a $WORK project for several years now.

 > PCC, to the best of my knowledge is still in the [very early] planning
 > stages.  One of its design choices would be to go pure SSA.  Another
 > option, closer to GCC (RTL), would be to retain existing code-gen
 > passes.  Tough choices.

I'm not sure why it's such a big deal, except that everything in gcc
is a big deal because gcc is such a mess inside.

Moving an existing representation to SSA just requires adding phi
nodes to the representation, writing a check pass to enforce the
single assignment property, and updating existing passes to maintain
the property -- in a language without proper algebraic data types this
is a bigger deal than otherwise but it does not seem like a
particularly major undertaking. Unless the representation is totally
wrong in other ways that need to be rectified first.

Maybe I'm missing something, or maybe I'm coming to this from a
strange point of view.

 > > Are you talking about a hypothetical future where pcc's backend grows
 > > an (additional, or replacement) SSA-based layer? Or is pcc's
 > > optimizing backend already SSA-based (per above, I don't know one way
 > > or the other) and you're talking about making that preserve debug
 > > info?
 > >
 > > Either way, it seems like adding DWARF support to the non-optimizing
 > > backend is an orthogonal issue.
 > 
 > I'm being fast and loose.  My reading of the code was that debug info
 > was being generated by the back of the front end (very roughly
 > "gimplify" in this diagram of GCC
 > https://gcc.gnu.org/projects/tree-ssa/#ssa).   It was pretty much hard
 > wired printfs, and explained to me why "-g -O" wasn't supported.

printfing from the back of the front end is definitely "totally wrong
in other ways that need to be rectified first" :(

-- 
David A. Holland
dholland%netbsd.org@localhost