[dylan] Fun compiler project: discrete compiler passes

--===============1799614420==
Content-Type: multipart/alternative; boundary=e89a8f23444923c21c04f9ad72cf

--e89a8f23444923c21c04f9ad72cf
Content-Type: text/plain; charset=UTF-8

Hello all,

For a long time, Hannes has wanted to restructure optimization and type
inferencing so that they worked in discrete compiler passes rather than the
current web of code that exists now.  This is something that would be
useful to have before his work on improvements to the type system could
land.

I thought this sounded interesting, so I figured I'd take a first look at
it and I revived some code that was removed in December, 1996 to switch
over to the current model of optimization.

That part was pretty easy.

An interesting and possibly exciting discovery that I made pretty quickly
is that since the compilation passes were removed in 1996, nothing has been
calling the dfmc-flow-graph ensure-invariants code
(sources/dfmc/flow-graph/checker.dylan).  Unfortunately, this can't just be
quickly enabled as various checks now fail and I'm not sure if that's due
to changed expectations, that we're getting along with invalid DFM state or
what.

That might be something fun to fix and to look into.

Next up, I ended up just commenting out the invariant checking and figured
I'd see what happened when I ran the optimization passes.

Unfortunately, this goes on pretty quickly to crash with an infinite
recursion due to the call to run-compilation-passes
in ensure-method-optimized from
sources/dfmc/conversion/define-method.dylan. (This call was added in 1997.)

Commenting that out lets us die in analyze-environments pass due to:

Internal error: No applicable method,
    applying {<sealed-generic-function>: temporary}
    to {<simple-object-vector>: {<method-reference>}}.

That happens in the reference-liftable? function in
sources/dfmc/flow-graph/closure.dylan. I haven't looked into that any
further.

It is worth pointing out that at this point, really-run-compilation-passes
was in the call stack so some stuff was manually calling that and so
everything wasn't cleanly and clearly using the compilation pass mechanisms.

Does this sound like an interesting project to anyone? (Hannes?)

Has anyone else played around at this depth in the code base in the last
decade?

 - Bruce

--e89a8f23444923c21c04f9ad72cf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello all,</div><div><br></div>For a long time, Hanne=
s has wanted to restructure optimization and type inferencing so that they =
worked in discrete compiler passes rather than the current web of code that=
 exists now. =C2=A0This is something that would be useful to have before hi=
s work on improvements to the type system could land.<div>
<br></div><div>I thought this sounded interesting, so I figured I&#39;d tak=
e a first look at it and I revived some code that was removed in December, =
1996 to switch over to the current model of optimization.</div><div><br>
</div><div>That part was pretty easy.</div><div><br></div><div>An interesti=
ng and possibly exciting discovery that I made pretty quickly is that since=
 the compilation passes were removed in 1996, nothing has been calling the =
dfmc-flow-graph ensure-invariants code (sources/dfmc/flow-graph/checker.dyl=
an). =C2=A0Unfortunately, this can&#39;t just be quickly enabled as various=
 checks now fail and I&#39;m not sure if that&#39;s due to changed expectat=
ions, that we&#39;re getting along with invalid DFM state or what.</div>
<div><br></div><div>That might be something fun to fix and to look into.</d=
iv><div><br></div><div>Next up, I ended up just commenting out the invarian=
t checking and figured I&#39;d see what happened when I ran the optimizatio=
n passes.</div>
<div><br></div><div>Unfortunately, this goes on pretty quickly to crash wit=
h an infinite recursion due to the call to run-compilation-passes in=C2=A0e=
nsure-method-optimized from sources/dfmc/conversion/define-method.dylan. (T=
his call was added in 1997.)</div>
<div><br></div><div>Commenting that out lets us die in analyze-environments=
 pass due to:</div><div><br></div><div>Internal error: No applicable method=
,</div><div>=C2=A0 =C2=A0 applying {&lt;sealed-generic-function&gt;: tempor=
ary}</div>
<div>=C2=A0 =C2=A0 to {&lt;simple-object-vector&gt;: {&lt;method-reference&=
gt;}}.<br></div><div><br></div><div>That happens in the reference-liftable?=
 function in sources/dfmc/flow-graph/closure.dylan. I haven&#39;t looked in=
to that any further.</div>
<div><br></div><div>It is worth pointing out that at this point, really-run=
-compilation-passes was in the call stack so some stuff was manually callin=
g that and so everything wasn&#39;t cleanly and clearly using the compilati=
on pass mechanisms.</div>
<div><br></div><div>Does this sound like an interesting project to anyone? =
(Hannes?)</div><div><br></div><div>Has anyone else played around at this de=
pth in the code base in the last decade?</div><div><br></div><div>=C2=A0- B=
ruce</div>
<div><br></div></div>

--e89a8f23444923c21c04f9ad72cf--

--===============1799614420==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers

--===============1799614420==--