[M3devel] subtle IR differences for platforms that are really the same

[Jay K]

> same source?


I did this a while ago but yes I suspect so. I'll have to restart the experiment.


 - Jay


________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Rodney M. Bates <rodney_bates at lcwb.coop>
Sent: Saturday, March 11, 2017 10:12 PM
To: m3devel at elegosoft.com
Subject: Re: [M3devel] subtle IR differences for platforms that are really the same

Hmm, looks like all reveal_opaque ops in a unit are are emitted at one time by
Revelation.Declare.  It uses a "Set" that has both a linear linked list and a
hash table.  The hash table sounds suspicious, but at a glance, I don't see
anything other than all the reveal_opaque's being emitted here, with nothing
interspersed. So that would only reorder multiple reveal_opaque's relative
to each other, with nothing in between them.


If there is only one, maybe something about the calls to Revelation.Declare in
Module.CompileModule?  The comment at :979:


  (**** moved below **** External.GenImports (t.externals); *)

would change where the reveal_opaque's were relative to other things.
Are both targets compiled using identical source code for Module.m3?


On 03/11/2017 06:38 AM, Jay K wrote:
> Trying to get back into things..not sure I sent this from a while ago..
>
>
>
> This is both a question and an explanation
> of hopefully an uncoming chnage, if I figure it out.
>
>
> Most platforms are almost the same.
>
> For example I386_FREEBSD and I386_NETBSD.
>
> You want their IR to generally be the same, along
> as they aren't printing their actual target name.
>
> And they mostly are.
>
> Here is a difference for example:
>
> jair:libm3 jay$ diff -du I386_NETBSD/NullRd.mc.txt I386_FREEBSD/NullRd.mc.txt
> --- I386_NETBSD/NullRd.mc.txt    2016-06-30 19:13:11.000000000 -0700
> +++ I386_FREEBSD/NullRd.mc.txt    2016-06-30 19:13:23.000000000 -0700
> @@ -44,7 +44,6 @@
>      declare_procedure     NullRd__Length 1 Int.32 0 0 F * p.7
>      declare_param     rd 4 4 Addr 34129018 F F 50 v.10
>      declare_local     _result 4 4 Int.32 425470580 F F 50 v.11
> -    reveal_opaque     34129018 -885236436
>      declare_opaque     483796623 -1651526519
>      declare_proctype     -2116580915 2 -915982019 2 0
>      declare_formal     n -1746782238
> @@ -85,6 +84,7 @@
>      declare_field     closed 416 8 509158269
>      declare_field     seekable 424 8 509158269
>      declare_field     intermittent 432 8 509158269
> +    reveal_opaque     34129018 -885236436
>      # Init
>                      -----LINE 22  -----
>      begin_procedure     p.5
>
>
> One line of the IR is moved.
> The meaning is the same (the IR is somewhat order-independent, e.g. for type declarations).
>
> What causes this?
>
> Do we output sometimes in hash order?
> And target affects that?
>
> Or when buffers fill up, and target length can affect that?
>
> I'd like to remove these differences.
> If it is a buffer length matter, I might just expand the buffers,
> as systems have far far more memory than when this was all written.
>
>
> If it is hash ordering matter -- one should avoid outputting data
> in hash order.
>
> so:
> 1. if anyone knows the difference, please tell me, before I debug it?
> 2. Ok if I make changes to converge the IR, i.e. I386_LINUX/Darwin/Solaris/FreeBSD/NetBSD/OpenBSD/Interix should all
> be the same, AMD64/ditto, SPARC32/ditto, SPARC64/ditto. Only variation should be endian and word size,
> and maybe NT vs. Posix but probably not.
>
>  - Jay
>
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>

--
Rodney Bates
rodney.m.bates at acm.org
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20170311/6ec26fc9/attachment.html>