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
