On 7 Sep 2016, at 15:00, Hannes Mehnert <[email protected]> wrote: > > On 07/09/2016 14:50, Anil Madhavapeddy wrote: >> The optimisation of the use of builtin functions would probably be drowned >> out by the extra 2 value allocations happening because a tuple is being >> returned. >> >> Would it be crazy to pass in a bool ref that could be reused to check for >> overflow? > > Are we afraid of allocation? Surely, a global bool ref could be used, > and it even might be safe considering single threading. But then we'd > need to allocate the tuple on the Caml side (is that cheaper?) or > provide an awkward API (add : t -> t -> t, carry : bool) reminding me of > unix errno (which I have no plans to replicate). > > better allocate than having a messed up API,
I'd prefer to allocate and have a good API, but then I would also prefer to not use compiler builtins that may introduce subtle optimisation bugs in the future -- or at least until we know that the optimisations are useful. E.g. the double fetch vulnerabilities that emerged from compiler builtins https://xenbits.xen.org/xsa/advisory-155.html (not directly applicable here, but my point is that I'd prefer a slightly slower but more consistent first cut at this library) -anil _______________________________________________ MirageOS-devel mailing list [email protected] https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
