Ok, I just tried this on x86 and 2704 is the dynamic slot offset of your
"i" or "j" Value, they are stored in slots on the global object, not on the
stack (the offset seemed pretty big for a stack slot..)
So the relevant code is CodeGenerator::visitLoadSlotT and
CodeGenerator::visitStoreSlotT. The MacroAssembler's loadUnboxedValue
method probably has to add the payload offset, at least our x86/x64/arm
implementations aren't doing that..
Jan
On Mon, Mar 23, 2015 at 9:01 AM, Jan de Mooij <jandemo...@gmail.com> wrote:
> Hey,
>
> Are you on mozilla-central or on an older release branch? I'm asking
> because we switched the default register allocator from linear scan to the
> backtracking allocator on mozilla-central. On older branches, the
> backtracking allocator is only used for asm.js code. You could try with
> --ion-regalloc=backtracking and --ion-regalloc=lsra and see if it makes a
> difference.
>
> So r3 is your stack pointer, right? One thing that comes to mind is
> OffsetToOtherHalfOfNunbox, you probably have to change the TYPE_INDEX and
> PAYLOAD_INDEX constants that are used there.
>
> Jan
>
>
> On Sun, Mar 22, 2015 at 8:52 PM, Cameron Kaiser <ckai...@floodgap.com>
> wrote:
>
>> Ion doesn't seem to respect how a Nunbox is laid out on big-endian
>> platforms (I imagine this is not very surprising). Consider this simple
>> script:
>>
>> js --ion-eager -e 'var i,j=0; for(i=0;i<50000;i++) { j+=i } print(j)'
>>
>> On big-endian, this asserts immediately with
>>
>> Assertion failure: safepoint->hasNunboxPayload(alloc)
>>
>> The stack value slot is at offset 8, but the stack payload slot is at 4.
>>
>> If I go into LIR.h and change the code from
>>
>> bool hasNunboxPayload(LAllocation payload) const {
>> if (payload.isArgument())
>> return true;
>> if (payload.isStackSlot() && hasValueSlot(payload.
>> toStackSlot()->slot())
>> )
>> return true;
>>
>> to
>>
>> bool hasNunboxPayload(LAllocation payload) const {
>> if (payload.isArgument())
>> return true;
>> if (payload.isStackSlot() &&
>> hasValueSlot(payload.toStackSlot()->slot()
>> + NUNBOX32_PAYLOAD_OFFSET)
>> )
>> return true;
>>
>> the assertion is satisfied, but the code generated is wrong. Oddly,
>> stores are correct, but loads are not. Here is one extract (PowerPC):
>>
>> 0x00fedd00: lwz r5,2704(r3) ; load actually comes from type
>> 0x00fedd04: trap ; debugging, ignore
>> 0x00fedd08: addo r6,r5,r4 ; add with overflow
>> 0x00fedd0c: mfxer r12
>> 0x00fedd10: mtcrf 128,r12
>> 0x00fedd14: clrlwi r12,r12,3
>> 0x00fedd18: mtxer r12
>> 0x00fedd1c: nop
>> 0x00fedd20: nop
>> 0x00fedd24: nop
>> 0x00fedd28: nop
>> 0x00fedd2c: bgt- 0xfee9d8
>> 0x00fedd30: stw r6,2708(r3) ; store actually stores to payload
>>
>> Note the two offsets are off by NUNBOX32_PAYLOAD_OFFSET, which on
>> big-endian systems is 4.
>>
>> I can't figure out where to change how stack slots are allocated so that
>> the value slot and the payload slot match and generate the right code. Any
>> suggestions?
>>
>> Cameron Kaiser
>>
>> _______________________________________________
>> dev-tech-js-engine-internals mailing list
>> dev-tech-js-engine-internals@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>>
>
>
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
