[Webkit-unassigned] [Bug 232079] [JSC][32bit] Use DataIC in Baseline JIT

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=232079

--- Comment #13 from Saam Barati <sbarati at apple.com> ---
Comment on attachment 442355
  --> https://bugs.webkit.org/attachment.cgi?id=442355
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=442355&action=review

>>> Source/JavaScriptCore/bytecode/CallLinkInfo.cpp:309
>>> +        //        with the code below.
>> 
>> this is the same for all the macro assemblers, hence the DisallowMacroScratchRegisterUsage scope. Don't think we need a FIXME here
> 
> My comment is probably obtuse, but the reason this is unsafe is precisely because the ARMv7 macro assembler ignores DisallowMacroScratchRegisterUsage. If you look in MacroAssemblerARMv7.h, it unconditionally uses the 'dataTempRegister' all over without ever checking the m_allowScratchRegister flag, hence the FIXME. Same applies to MIPS and RISCV64. ARM64/ARM64E and x86 are OK.

Yeah, we should make DisallowMacroScratchRegisterUsage a thing for those assemblers.

>>> Source/JavaScriptCore/jit/CCallHelpers.h:874
>>> +    }
>> 
>> can't this just construct a tuple and return std::get<Index>?
> 
> I think this one (the JSVALUE64 version only) could, I admit I have not thought of that as I was thinking of the more generic algorithm that works for JSVALUE32_64 as well where you need to cherry pick your register in a more peculiar way when passing 64-bit values. The JSVALUE64 version is just a simplified version of that which indeed appears to be identical to the std::tuple method.
> 
> Maybe it is better to keep the two platforms to use the same algorithm structure so it's easier on the next reader of the JSVALUE32_64 code that is perhaps less obvious?

I don't have a strong preference. I think it's fine to leave it as is.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211027/5a21b5e5/attachment.htm>