[MLton] Object allocation code path

Jeffrey Murphy <[email protected]> Fri, 28 Jan 2022 00:46:38 -0500
Newsgroups gmane.comp.lang.ml.mlton.devel
Message-ID <CAJ36g20gFx8nKkYNHn-W12Gc1N9QzgvXZKM3wu9v+8t+qxN20w@mail.gmail.com>
--===============4386490568847469161==
Content-Type: multipart/alternative; boundary="00000000000009cebf05d69df691"

--00000000000009cebf05d69df691
Content-Type: text/plain; charset="UTF-8"

Hi,

I'm currently working on reading through the compiler code and
understanding how variables go from the AST layer through to the machine
layer. I would like to experiment with how objects are packed. I've been
looking at, eg, packed-representation, and trying to understand how a
(normal) variable associated with a function is transformed into an
object/offset. Are there detailed descriptions of how MLton transforms code
at each layer, other than what is on mlton.org or in "An LLVM back-end for
MLton" (Leibig)?

I'd like to understand how MLton tracks and transforms SML and the
associated functions so that I can influence how normals are allocated. For
example, (this is contrived!), if I wanted to pack normals together that
are allocated by functions that begin with the letter "t", how can I more
easily learn which source files, or passes should I focus on with respect
to how the code is parsed and transformed?   I think after the coreml->xml
transform, function names are discarded. Additional variables may be
introduced (for example I think LocalRef might convert refs in some
circumstances) and so if the function name is discarded by the time SSA is
reached...

I'm also interested in how the call graph is organized and computed, eg,
inline.fun, multi.fun. Is it just computed on-demand/as-needed? I can read
the code (and I am!) but any additional explanations are welcome! E.g.
another example would be if I wanted to look at packing objects based on
how related they are in the call graph.

thanks,
jeff

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

<div dir=3D"ltr">Hi,<div><br></div><div>I&#39;m currently working on readin=
g through the compiler code and understanding how variables go from the AST=
 layer through to the machine layer. I would like to experiment with how ob=
jects are packed. I&#39;ve been looking at, eg, packed-representation, and =
trying to understand how a (normal) variable associated with a function is =
transformed into an object/offset. Are there detailed descriptions of how M=
Lton transforms code at each layer, other than what is on <a href=3D"http:/=
/mlton.org">mlton.org</a> or in &quot;An LLVM back-end for MLton&quot; (Lei=
big)?=C2=A0</div><div><br></div><div>I&#39;d like to understand how MLton=
=C2=A0tracks and transforms SML and the associated functions so that=C2=A0I=
 can influence how normals are allocated. For example, (this is contrived!)=
, if I wanted to pack normals together that are allocated by functions that=
 begin with the letter &quot;t&quot;, how can I more easily learn which sou=
rce files, or passes should I focus on with respect to how the code is pars=
ed and transformed?=C2=A0 =C2=A0I think after the coreml-&gt;xml transform,=
 function names are discarded. Additional variables may be introduced (for =
example I think LocalRef might convert refs in some circumstances) and so i=
f the function name is discarded by the time SSA is reached...</div><div><b=
r></div><div>I&#39;m also interested in how the call graph is organized and=
 computed, eg, inline.fun, multi.fun. Is it just computed on-demand/as-need=
ed? I can read the code (and I am!) but any additional explanations are wel=
come! E.g. another example would be if I wanted to look at packing=C2=A0obj=
ects based on how related they are in the call graph.=C2=A0</div><div><br><=
/div><div>thanks,</div><div>jeff</div><div><br></div><div><br></div><div><b=
r></div><div><br></div></div>

--00000000000009cebf05d69df691--


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


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

_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel

--===============4386490568847469161==--