Here is another possibility: in low level IR explode double values into pairs of low-level values.
d2 = Mul d0, d1 becomes smth like (i20, i21) = Mul (i00, i01), (i10, i11) that would require a minor change in the pipeline to allow multiple return values but I think it might be less painful than supporting register pairs across the pipeline. -- Vyacheslav Egorov On Mon, Aug 13, 2012 at 11:34 AM, Vyacheslav Egorov <vego...@chromium.org> wrote: > Are you planning to allocate a couple of general purpose registers to > represent a double? Do these registers have to be ordered? (e.g. do > you need r_{N}, r_{N+1}) > > Do you want a single build of V8 work both on a hardware that supports > real double registers and that does not? > > If you don't need binary portability then I don't think you need to > extend unallocated policies. Just change "interpretation" of > DOUBLE_REGISTER policy everywhere. > > Otherwise, yeah, you need new policies (which would require some bit > stealing cause LUnallocated is packed pretty tight already). > > In any case it would require some adjustments in allocator to get > "what interferes with what" right. > > -- > Vyacheslav Egorov > > > On Mon, Aug 13, 2012 at 7:53 AM, Evgeny Baskakov > <evgeny.baska...@gmail.com> wrote: >> Hi guys, >> >> I'm looking for ways to modify the Crankshaft compilation mode to make it >> work without 64-bit hardware registers. >> >> Could someone give me brief guidelines? Is it possible at all, without the >> whole V8 codebase reworking? >> >> My first impulse is to extend the LUnallocated policies set and make the >> codegen distinguish between single and coupled registers. Then, the lithium >> codegen would use the CPU-based code stubs instead of native double-related >> instructions. What pitfalls should I be aware of here? >> >> --Evgeny >> >> -- >> v8-users mailing list >> v8-users@googlegroups.com >> http://groups.google.com/group/v8-users -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users