[MLton-devel] -profile time and the native codegen

[Matthew Fluet]

> > I'm pretty sure that the only new blocks created by the native-codegen are
> > register allocation compensation blocks (which essentially do nothing more
> > than shuffle values around).  This didn't used to be the case before
> > Arith, Runtime, and CCalls were transfers.
>
> Great.  I figured it wasn't too bad these days.

Well, it turns out that there are other problems.  The register allocator
can emit a number of instructions immediately after a block's label,
before processing the first statment.  That means that there can be
instructions before the profile label.  (Note, this is independent of
introducing new blocks.)  This wasn't an issue with the old profiling,
because I associated profile info with each block.

> I would think the whole mess could be abstracted into a function like
>
> 	val newProfileLabel: ProfileLabel.t -> ProfileLabel.t
>
> that is passed down as part of the transinfo.
>
> Make sense?

Yes, except that the x86 codegen knows only about Label.t's.  (A
ProfileLabel.t is converted into a .global and a label.)

Given these two problems, I'd really suggest going back to an x86.Block.T
looking like:

T {entry: Entry.t,
   profile: ProfileLabel.t option,
   statements: Assembly.t list,
   transfer: Transfer.t}

and I will output the profileLabel with the block label, ensuring that no
instructions fall between the two.  I'll be checking that in in about
30mins after running through a self-compile and regressions.




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel