Vincent Laviron
Vincent Laviron
> If the branch after load is for ordering with future stores to the same location, we may be able to avoid it for immutable locations? We don't know which...
> Maybe @lthls has a list somewhere. I don't keep a list around, but I can point out a few known cases: - value let-rec - recursive modules - TMC...
We only support atomic access on structures with a single field. We should be able to generalize that to atomic arrays if we wanted to, and it's likely possible to...
> @lthls That indirection could lead to a cache miss that costs a hundred cycles or more. A hundred cycles is pretty cheap compared to the time required to implement...
We're not very fond of the underscore, so @Ekdohibs suggests `module as of then` and @chambart proposes `virtual module downto begin`
As a workaround, you should be able to pack the individual plugin units before making a library: ```shell-session $ ocamlc -pack -o c.cmo a.cmo b.cmo $ ocamlc -a -o c.cma...
Fixed on trunk by #13376.
> In particular, `Atomic.read x + Atomic.read y` also has unspecified atomic-read order and everyone is fine with that. I'm not ! But I concur that I can't get many...
You can already implement something almost as efficient with the existing primitives (only one additional subtraction): ```ocaml (* A statically allocated string will always have the same address *) let...
> Is this guaranteed to work in future versions of the compiler? As much as any other `Obj`-using code, I would say. Although the test that I've provided is not...