Bug 214243 – [JSC] We should keep unaligned access feature in certain architectures in macro-assembler

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Yusuke Suzuki]

[JSC] We should keep unaligned access feature in certain architectures in macro-assembler

[Yusuke Suzuki]

Created attachment 404119 [details]
Patch

[Darin Adler]

Comment on attachment 404119 [details]
Patch

Seems like it might help us catch mistakes if we had an explicit loadUnalignedPtr just so we could have the assertion for call sites where we think things are aligned.

[Yusuke Suzuki]

(In reply to Darin Adler from comment #2)
> Comment on attachment 404119 [details]
> Patch
> 
> Seems like it might help us catch mistakes if we had an explicit
> loadUnalignedPtr just so we could have the assertion for call sites where we
> think things are aligned.

Yeah, this is good, but I think currently, we have no way to enforce this condition at B3, e.g. B3 can freely compute addresses in any forms, while it is unlikely I think, this is possible that we will generate BaseIndex with Scale2 while it is pointing an aligned position to the pointer (Scale8). So, for now, this would be simpler solution.

[Yusuke Suzuki]

I'll land it once EWS JSC build is done, since it is removing assertions which can occur only when Debug build is enabled, and this assertion was not hit in mac-debug previously. So, except for building, EWS status must not be changed.

[EWS]

Committed r264287: <https://trac.webkit.org/changeset/264287>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 404119 [details].

[Radar WebKit Bug Importer]

<rdar://problem/65444830>

[Keith Miller]

Comment on attachment 404119 [details]
Patch

We can probably just remove the assertion. I added it because I wanted to catch cases where we used loadPtr but passed Scale64 for arm64_32. Since it's harder to debug that from the bad data later. I can just restore the assertion locally as I continue working on arm64_32 JITs.