Skip to content

Commit 6652136

Browse files
committed
clarify comment
1 parent 820f17b commit 6652136

File tree

2 files changed

+16
-7
lines changed

2 files changed

+16
-7
lines changed

backend/amd64/emit.ml

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1689,7 +1689,10 @@ let emit_instr ~first ~fallthrough i =
16891689
(* +0.0 *)
16901690
I.xorpd (res i 0) (res i 0)
16911691
| _ ->
1692-
(* float32 constants still take up 8 bytes; we load the lower half. *)
1692+
(* float32 constants take up 8 bytes when we emit them with
1693+
[float_literal] (see the conversion from int32 to int64 below). Thus,
1694+
we load the lower half. Note that this is different from Cmm 32-bit
1695+
floats ([Csingle]), which are emitted as 4-byte constants. *)
16931696
let lbl = add_float_constant (Int64.of_int32 f) in
16941697
I.movss (mem64_rip REAL4 (emit_label lbl)) (res i 0))
16951698
| Lop (Const_float f) -> (

backend/arm64/emit.ml

Lines changed: 12 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -745,8 +745,11 @@ let vec128_literals = ref ([] : (Cmm.vec128_bits * L.t) list)
745745
let add_literal p f =
746746
try List.assoc f !p
747747
with Not_found ->
748-
(* CR sspies: Should the literals really be in the text section? They are
749-
currently emitted at the end of a function in the text section. *)
748+
(* CR sspies: The [Text] section here is incorrect. We should be in the
749+
respective section of the literal type (i.e., 16 or 8 bytes). The code
750+
below uses the [Text] section, because that is the section that we are in
751+
when we emit literals in the function body. Only macOS currently switches
752+
to a dedicated section. *)
750753
let lbl = L.create Text in
751754
p := (f, lbl) :: !p;
752755
lbl
@@ -765,6 +768,8 @@ let emit_literals p align emit_literal =
765768
~names:["__TEXT,__literal" ^ Int.to_string align]
766769
~flags:None
767770
~args:[Int.to_string align ^ "byte_literals"];
771+
(* CR sspies: The following section is incorrect. We are in a data section
772+
here. Fix this when cleaning up the section mechanism. *)
768773
D.unsafe_set_interal_section_ref Text);
769774
D.align ~bytes:align;
770775
List.iter emit_literal !p;
@@ -1415,9 +1420,10 @@ let emit_instr i =
14151420
DSL.ins I.FMOV
14161421
[| DSL.emit_reg i.res.(0); DSL.imm_float (Int32.float_of_bits f) |]
14171422
else
1418-
(* float32 constants still take up 8 bytes; we load the lower half. *)
1419-
(* CR sspies: Check whether this is 32-bit or 64-bit. There is currently
1420-
ambiguity about this. *)
1423+
(* float32 constants take up 8 bytes when we emit them with
1424+
[float_literal] (see the conversion from int32 to int64 below). Thus,
1425+
we load the lower half. Note that this is different from Cmm 32-bit
1426+
floats ([Csingle]), which are emitted as 4-byte constants. *)
14211427
let lbl = float_literal (Int64.of_int32 f) in
14221428
emit_load_literal i.res.(0) lbl
14231429
| Lop (Const_float f) ->
@@ -2202,7 +2208,7 @@ let end_assembly () =
22022208
(* [efa_16] is [D.uint16 (Numbers.Uint16.of_int_exn n)] in
22032209
mshinwell/ocaml#gdb-names-gpr x86 emitter *)
22042210
efa_16 = (fun n -> D.uint16 (Numbers.Uint16.of_nonnegative_int_exn n));
2205-
(* [efa_16] is [D.uint32 (Numbers.Uint32.of_int32 n)] in
2211+
(* [efa_32] is [D.uint32 (Numbers.Uint32.of_int32 n)] in
22062212
mshinwell/ocaml#gdb-names-gpr x86 emitter *)
22072213
(* CR sspies: for some reason, we can get negative numbers here *)
22082214
efa_32 = (fun n -> D.int32 n);

0 commit comments

Comments
 (0)