[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