[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'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'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 "An LLVM back-end for MLton" (Lei= big)?=C2=A0</div><div><br></div><div>I'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 "t", 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->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'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==--