[M3devel] slight IR variation among targets?

Jay K jay.krell at cornell.edu
Fri Jul 1 04:34:02 CEST 2016


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 (and possibly code, but here just the IR)
to generally be the same, along
as long they aren't printing their actual target name.

And they mostly are.

Here is a different 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.

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.


 - Jay

 		 	   		  


More information about the M3devel mailing list