Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2887053003:
MIPS[64]: Reland of `Fix unaligned arguments storage in Wasm-to-interpreter entry` (Closed)
|
Created:
3 years, 7 months ago by ivica.bogosavljevic Modified:
3 years, 6 months ago CC:
v8-reviews_googlegroups.com, wasm-v8_google.com Target Ref:
refs/heads/master Project:
v8 Visibility:
Public. |
DescriptionMIPS[64]: Reland of `Fix unaligned arguments storage in Wasm-to-interpreter entry`
Reland 84ff6e4c1997b63c01e95504c31ee6c5504430d5
In Wasm-to-interpeter entry creation, arguments for the interpreter
are stored in an argument buffer. Depending on the order of the
arguments some arguments may be misaligned and this causes crashes
on those architectures that do not support unaligned memory access.
TEST=mjsunit/wasm/interpreter
BUG=
Review-Url: https://codereview.chromium.org/2887053003
Cr-Commit-Position: refs/heads/master@{#45703}
Committed: https://chromium.googlesource.com/v8/v8/+/656c6d5eeae0048863bd18007231c07b48b5a9b5
Patch Set 1 #
Total comments: 4
Patch Set 2 : Fix the issue a bit differently #
Total comments: 2
Patch Set 3 : Simplifications. #
Total comments: 1
Patch Set 4 : Address code review remarks #
Total comments: 1
Patch Set 5 : Address code review remarks 2 #Messages
Total messages: 32 (9 generated)
ivica.bogosavljevic@imgtec.com changed reviewers: + titzer@chromium.org
PTAL The new implementation uses aligned StackSlot The original code review is here: https://codereview.chromium.org/2705293011
ivica.bogosavljevic@imgtec.com changed reviewers: + ahaas@chromium.org, bmeurer@chromium.org, clemensh@chromium.org
PTAL Uses StackSlot alignment to fix the bug with the unaligned parameters for WASM interpreter
I don't get why all these changes are needed. Isn't the only requirement that the whole stack slot is 8-byte aligned? With your change, we would waste stack space by making each single stack slot 8-byte aligned. https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc File src/compiler/wasm-compiler.cc (right): https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, return_size_bytes), 8)); Wouldn't this be the only change required? https://codereview.chromium.org/2887053003/diff/1/src/utils.h File src/utils.h (right): https://codereview.chromium.org/2887053003/diff/1/src/utils.h#newcode190 src/utils.h:190: DCHECK(multiple && ((multiple & (multiple - 1)) == 0)); There is base::bits::IsPowerOfTwo64.
Each double and int64 has to be eight bytes aligned. So the simplest way to do this is to keep all parameters eight bytes aligned. As far as stack consumption is concerned, it would take many thousands of parameters passed or many recursive call to Wasm interpreter in order to drain space on stack, and I don't think these are regular cases. Nevertheless, I could limit the impact of the change to MIPS only, if that is more appropriate. On 2017/05/18 11:52:05, Clemens Hammacher wrote: > I don't get why all these changes are needed. Isn't the only requirement that > the whole stack slot is 8-byte aligned? > With your change, we would waste stack space by making each single stack slot > 8-byte aligned. > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc > File src/compiler/wasm-compiler.cc (right): > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... > src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, > return_size_bytes), 8)); > Wouldn't this be the only change required? > > https://codereview.chromium.org/2887053003/diff/1/src/utils.h > File src/utils.h (right): > > https://codereview.chromium.org/2887053003/diff/1/src/utils.h#newcode190 > src/utils.h:190: DCHECK(multiple && ((multiple & (multiple - 1)) == 0)); > There is base::bits::IsPowerOfTwo64.
https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc File src/compiler/wasm-compiler.cc (right): https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, return_size_bytes), 8)); On 2017/05/18 11:52:05, Clemens Hammacher wrote: > Wouldn't this be the only change required? Unfortunately no. if you had three parameters, first 4 bytes, second 8 bytes and third 8 bytes, the first parameter would be 8 byte aligned but second and third wouldn't. https://codereview.chromium.org/2887053003/diff/1/src/utils.h File src/utils.h (right): https://codereview.chromium.org/2887053003/diff/1/src/utils.h#newcode190 src/utils.h:190: DCHECK(multiple && ((multiple & (multiple - 1)) == 0)); On 2017/05/18 11:52:05, Clemens Hammacher wrote: > There is base::bits::IsPowerOfTwo64. Acknowledged.
On 2017/05/18 at 12:21:43, ivica.bogosavljevic wrote: > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc > File src/compiler/wasm-compiler.cc (right): > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... > src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, return_size_bytes), 8)); > On 2017/05/18 11:52:05, Clemens Hammacher wrote: > > Wouldn't this be the only change required? > > Unfortunately no. if you had three parameters, first 4 bytes, second 8 bytes and third 8 bytes, the first parameter would be 8 byte aligned but second and third wouldn't. Before your change, we were reading them back with ReadUnalignedValue, and writing the result using WriteUnalignedValue. Why is that not sufficient?
On 2017/05/18 at 12:58:17, Clemens Hammacher wrote: > On 2017/05/18 at 12:21:43, ivica.bogosavljevic wrote: > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc > > File src/compiler/wasm-compiler.cc (right): > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... > > src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, return_size_bytes), 8)); > > On 2017/05/18 11:52:05, Clemens Hammacher wrote: > > > Wouldn't this be the only change required? > > > > Unfortunately no. if you had three parameters, first 4 bytes, second 8 bytes and third 8 bytes, the first parameter would be 8 byte aligned but second and third wouldn't. > > Before your change, we were reading them back with ReadUnalignedValue, and writing the result using WriteUnalignedValue. Why is that not sufficient? Oh, one more change needed: Use "jsgraph()->machine()->Unaligned{Load,Store}()" in WasmGraphBuilder::BuildWasmInterpreterEntry (thanks @ahaas for pointing this out)
On 2017/05/18 13:25:31, Clemens Hammacher wrote: > On 2017/05/18 at 12:58:17, Clemens Hammacher wrote: > > On 2017/05/18 at 12:21:43, ivica.bogosavljevic wrote: > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc > > > File src/compiler/wasm-compiler.cc (right): > > > > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... > > > src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, > return_size_bytes), 8)); > > > On 2017/05/18 11:52:05, Clemens Hammacher wrote: > > > > Wouldn't this be the only change required? > > > > > > Unfortunately no. if you had three parameters, first 4 bytes, second 8 bytes > and third 8 bytes, the first parameter would be 8 byte aligned but second and > third wouldn't. > > > > Before your change, we were reading them back with ReadUnalignedValue, and > writing the result using WriteUnalignedValue. Why is that not sufficient? > > Oh, one more change needed: Use "jsgraph()->machine()->Unaligned{Load,Store}()" > in WasmGraphBuilder::BuildWasmInterpreterEntry (thanks @ahaas for pointing this > out) This has a long history. Originally I fixed the issue by writing to buffer using UnalignedLoad/UnalignedStore and reading from the buffer using ReadUnalignedValue. This is the simple and straightforward solution, although a little bit unoptimal for MIPS part. After some consideration, titzer decided that we should naturally align the arguments in the buffer. So I landed StackSlot alignment in order to have aligned StackSlot and now I am landing this in order to finally fix the issue.
On 2017/05/18 at 14:09:56, ivica.bogosavljevic wrote: > On 2017/05/18 13:25:31, Clemens Hammacher wrote: > > On 2017/05/18 at 12:58:17, Clemens Hammacher wrote: > > > On 2017/05/18 at 12:21:43, ivica.bogosavljevic wrote: > > > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc > > > > File src/compiler/wasm-compiler.cc (right): > > > > > > > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... > > > > src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, > > return_size_bytes), 8)); > > > > On 2017/05/18 11:52:05, Clemens Hammacher wrote: > > > > > Wouldn't this be the only change required? > > > > > > > > Unfortunately no. if you had three parameters, first 4 bytes, second 8 bytes > > and third 8 bytes, the first parameter would be 8 byte aligned but second and > > third wouldn't. > > > > > > Before your change, we were reading them back with ReadUnalignedValue, and > > writing the result using WriteUnalignedValue. Why is that not sufficient? > > > > Oh, one more change needed: Use "jsgraph()->machine()->Unaligned{Load,Store}()" > > in WasmGraphBuilder::BuildWasmInterpreterEntry (thanks @ahaas for pointing this > > out) > > This has a long history. Originally I fixed the issue by writing to buffer using UnalignedLoad/UnalignedStore > and reading from the buffer using ReadUnalignedValue. This is the simple and straightforward > solution, although a little bit unoptimal for MIPS part. After some consideration, > titzer decided that we should naturally align the arguments in the buffer. > So I landed StackSlot alignment in order to have aligned StackSlot and now I am > landing this in order to finally fix the issue. I am aware of that history (if you are referring to this CL: https://codereview.chromium.org/2705293011). It later turned out, however, that both approaches (padding each element or padding the whole buffer) were insufficient, since the whole buffer / stack slot was not properly aligned. This is fixed now. So now we can reevaluate which solution would be better. And I argue that aligning each element is not needed, not even on mips. It's totally sufficient to ensure correct alignment of the whole buffer. Each element is read and written exactly once, so the runtime overhead for the unaligned load/store on mips is negligible.
On 2017/05/18 14:27:59, Clemens Hammacher wrote: > On 2017/05/18 at 14:09:56, ivica.bogosavljevic wrote: > > On 2017/05/18 13:25:31, Clemens Hammacher wrote: > > > On 2017/05/18 at 12:58:17, Clemens Hammacher wrote: > > > > On 2017/05/18 at 12:21:43, ivica.bogosavljevic wrote: > > > > > > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc > > > > > File src/compiler/wasm-compiler.cc (right): > > > > > > > > > > > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... > > > > > src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, > > > return_size_bytes), 8)); > > > > > On 2017/05/18 11:52:05, Clemens Hammacher wrote: > > > > > > Wouldn't this be the only change required? > > > > > > > > > > Unfortunately no. if you had three parameters, first 4 bytes, second 8 > bytes > > > and third 8 bytes, the first parameter would be 8 byte aligned but second > and > > > third wouldn't. > > > > > > > > Before your change, we were reading them back with ReadUnalignedValue, and > > > writing the result using WriteUnalignedValue. Why is that not sufficient? > > > > > > Oh, one more change needed: Use > "jsgraph()->machine()->Unaligned{Load,Store}()" > > > in WasmGraphBuilder::BuildWasmInterpreterEntry (thanks @ahaas for pointing > this > > > out) > > > > This has a long history. Originally I fixed the issue by writing to buffer > using UnalignedLoad/UnalignedStore > > and reading from the buffer using ReadUnalignedValue. This is the simple and > straightforward > > solution, although a little bit unoptimal for MIPS part. After some > consideration, > > titzer decided that we should naturally align the arguments in the buffer. > > So I landed StackSlot alignment in order to have aligned StackSlot and now I > am > > landing this in order to finally fix the issue. > > I am aware of that history (if you are referring to this CL: > https://codereview.chromium.org/2705293011). > It later turned out, however, that both approaches (padding each element or > padding the whole buffer) were insufficient, since the whole buffer / stack slot > was not properly aligned. This is fixed now. So now we can reevaluate which > solution would be better. And I argue that aligning each element is not needed, > not even on mips. It's totally sufficient to ensure correct alignment of the > whole buffer. Each element is read and written exactly once, so the runtime > overhead for the unaligned load/store on mips is negligible. I am ok with both approaches. But work UnalignedRead/UnalignedWrite we do not need StackSlot alignment to be eight, because this aligns only the first element.
On 2017/05/19 at 08:51:53, ivica.bogosavljevic wrote: > On 2017/05/18 14:27:59, Clemens Hammacher wrote: > > On 2017/05/18 at 14:09:56, ivica.bogosavljevic wrote: > > > On 2017/05/18 13:25:31, Clemens Hammacher wrote: > > > > On 2017/05/18 at 12:58:17, Clemens Hammacher wrote: > > > > > On 2017/05/18 at 12:21:43, ivica.bogosavljevic wrote: > > > > > > > > > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc > > > > > > File src/compiler/wasm-compiler.cc (right): > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... > > > > > > src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, > > > > return_size_bytes), 8)); > > > > > > On 2017/05/18 11:52:05, Clemens Hammacher wrote: > > > > > > > Wouldn't this be the only change required? > > > > > > > > > > > > Unfortunately no. if you had three parameters, first 4 bytes, second 8 > > bytes > > > > and third 8 bytes, the first parameter would be 8 byte aligned but second > > and > > > > third wouldn't. > > > > > > > > > > Before your change, we were reading them back with ReadUnalignedValue, and > > > > writing the result using WriteUnalignedValue. Why is that not sufficient? > > > > > > > > Oh, one more change needed: Use > > "jsgraph()->machine()->Unaligned{Load,Store}()" > > > > in WasmGraphBuilder::BuildWasmInterpreterEntry (thanks @ahaas for pointing > > this > > > > out) > > > > > > This has a long history. Originally I fixed the issue by writing to buffer > > using UnalignedLoad/UnalignedStore > > > and reading from the buffer using ReadUnalignedValue. This is the simple and > > straightforward > > > solution, although a little bit unoptimal for MIPS part. After some > > consideration, > > > titzer decided that we should naturally align the arguments in the buffer. > > > So I landed StackSlot alignment in order to have aligned StackSlot and now I > > am > > > landing this in order to finally fix the issue. > > > > I am aware of that history (if you are referring to this CL: > > https://codereview.chromium.org/2705293011). > > It later turned out, however, that both approaches (padding each element or > > padding the whole buffer) were insufficient, since the whole buffer / stack slot > > was not properly aligned. This is fixed now. So now we can reevaluate which > > solution would be better. And I argue that aligning each element is not needed, > > not even on mips. It's totally sufficient to ensure correct alignment of the > > whole buffer. Each element is read and written exactly once, so the runtime > > overhead for the unaligned load/store on mips is negligible. > > I am ok with both approaches. But work UnalignedRead/UnalignedWrite we do > not need StackSlot alignment to be eight, because this aligns only > the first element. Yeah, sorry, I did not see that the whole stack slot alignment CL was only needed to avoid unaligned loads and stores in the interpreter entry. Given that this CL has landed already, I would still prefer the least intrusive fix to the problem, which is using unaligned loads and stores for all accesses to this buffer. Especially since this only affects a small number of architectures. May I ask the other reviewers for a quick show of hands for their preference?
On 2017/05/19 at 09:18:21, clemensh wrote: > On 2017/05/19 at 08:51:53, ivica.bogosavljevic wrote: > > On 2017/05/18 14:27:59, Clemens Hammacher wrote: > > > On 2017/05/18 at 14:09:56, ivica.bogosavljevic wrote: > > > > On 2017/05/18 13:25:31, Clemens Hammacher wrote: > > > > > On 2017/05/18 at 12:58:17, Clemens Hammacher wrote: > > > > > > On 2017/05/18 at 12:21:43, ivica.bogosavljevic wrote: > > > > > > > > > > > > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.cc > > > > > > > File src/compiler/wasm-compiler.cc (right): > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2887053003/diff/1/src/compiler/wasm-compiler.... > > > > > > > src/compiler/wasm-compiler.cc:2819: std::max(args_size_bytes, > > > > > return_size_bytes), 8)); > > > > > > > On 2017/05/18 11:52:05, Clemens Hammacher wrote: > > > > > > > > Wouldn't this be the only change required? > > > > > > > > > > > > > > Unfortunately no. if you had three parameters, first 4 bytes, second 8 > > > bytes > > > > > and third 8 bytes, the first parameter would be 8 byte aligned but second > > > and > > > > > third wouldn't. > > > > > > > > > > > > Before your change, we were reading them back with ReadUnalignedValue, and > > > > > writing the result using WriteUnalignedValue. Why is that not sufficient? > > > > > > > > > > Oh, one more change needed: Use > > > "jsgraph()->machine()->Unaligned{Load,Store}()" > > > > > in WasmGraphBuilder::BuildWasmInterpreterEntry (thanks @ahaas for pointing > > > this > > > > > out) > > > > > > > > This has a long history. Originally I fixed the issue by writing to buffer > > > using UnalignedLoad/UnalignedStore > > > > and reading from the buffer using ReadUnalignedValue. This is the simple and > > > straightforward > > > > solution, although a little bit unoptimal for MIPS part. After some > > > consideration, > > > > titzer decided that we should naturally align the arguments in the buffer. > > > > So I landed StackSlot alignment in order to have aligned StackSlot and now I > > > am > > > > landing this in order to finally fix the issue. > > > > > > I am aware of that history (if you are referring to this CL: > > > https://codereview.chromium.org/2705293011). > > > It later turned out, however, that both approaches (padding each element or > > > padding the whole buffer) were insufficient, since the whole buffer / stack slot > > > was not properly aligned. This is fixed now. So now we can reevaluate which > > > solution would be better. And I argue that aligning each element is not needed, > > > not even on mips. It's totally sufficient to ensure correct alignment of the > > > whole buffer. Each element is read and written exactly once, so the runtime > > > overhead for the unaligned load/store on mips is negligible. > > > > I am ok with both approaches. But work UnalignedRead/UnalignedWrite we do > > not need StackSlot alignment to be eight, because this aligns only > > the first element. > > Yeah, sorry, I did not see that the whole stack slot alignment CL was only needed to avoid unaligned loads and stores in the interpreter entry. > Given that this CL has landed already, I would still prefer the least intrusive fix to the problem, which is using unaligned loads and stores for all accesses to this buffer. Especially since this only affects a small number of architectures. > > May I ask the other reviewers for a quick show of hands for their preference? If using UnalignedRead/UnalignedWrite in the WasmInterpreterEntry is all that is required to fix this issue for mips, then this would be my preferred solution. The wasm interpreter is not optimized for speed anyways, so I don't think it matters too much if the entry is a bit slower because of UnalignedRead/UnalignedWrite.
PTAL
ping
Sorry for the delay. Forgot about this over the weekend ;) Looking much better now, but still too much complexity. See inline comment. https://codereview.chromium.org/2887053003/diff/20001/src/compiler/wasm-compi... File src/compiler/wasm-compiler.cc (right): https://codereview.chromium.org/2887053003/diff/20001/src/compiler/wasm-compi... src/compiler/wasm-compiler.cc:2831: if (offset_aligned || You introduce lots of code duplication here. Please extract a method like this: const Operator* GetSafeStoreOperator(MachineOperatorBuilder* machine, int offset, wasm::ValueType type) { int alignment = offset % (1 << ElementSizeLog2Of(type)); if (alignment == 0 || machine->UnalignedStoreSupported( MachineType::TypeForRepresentation(type), 0)) { StoreRepresentation rep(type, WriteBarrierKind::kNoWriteBarrier); return machine->Store(rep); } UnalignedStoreRepresentation rep(type); return machine->UnalignedStore(rep); } And then just use this to generate the nodes: *effect_ = graph()->NewNode( GetSafeStoreOperator(jsgraph()->machine(), offset, param_rep), arg_buffer, ...
https://codereview.chromium.org/2887053003/diff/20001/src/compiler/wasm-compi... File src/compiler/wasm-compiler.cc (right): https://codereview.chromium.org/2887053003/diff/20001/src/compiler/wasm-compi... src/compiler/wasm-compiler.cc:2831: if (offset_aligned || On 2017/05/23 12:35:12, Clemens Hammacher wrote: > You introduce lots of code duplication here. > Please extract a method like this: > > const Operator* GetSafeStoreOperator(MachineOperatorBuilder* machine, > int offset, wasm::ValueType type) { > int alignment = offset % (1 << ElementSizeLog2Of(type)); > if (alignment == 0 || machine->UnalignedStoreSupported( > MachineType::TypeForRepresentation(type), 0)) { > StoreRepresentation rep(type, WriteBarrierKind::kNoWriteBarrier); > return machine->Store(rep); > } > UnalignedStoreRepresentation rep(type); > return machine->UnalignedStore(rep); > } > > And then just use this to generate the nodes: > *effect_ = graph()->NewNode( > GetSafeStoreOperator(jsgraph()->machine(), offset, param_rep), > arg_buffer, ... I like this approach better, consider it done
PTAL
Nice refactoring! One last thing. https://codereview.chromium.org/2887053003/diff/40001/src/compiler/wasm-compi... File src/compiler/wasm-compiler.h (right): https://codereview.chromium.org/2887053003/diff/40001/src/compiler/wasm-compi... src/compiler/wasm-compiler.h:300: const Operator* GetSafeStoreOperator(MachineOperatorBuilder* machine, Since this is a method on the WasmGraphBuilder, you don't need to pass the MachineOperatorBuilder explicitly. Just use "jsgraph()->machine()" inside the method. Alternatively, leave it as is but define it in an anonymous namespace in wasm-compiler.cc.
PTAL
https://codereview.chromium.org/2887053003/diff/60001/src/compiler/wasm-compi... File src/compiler/wasm-compiler.h (right): https://codereview.chromium.org/2887053003/diff/60001/src/compiler/wasm-compi... src/compiler/wasm-compiler.h:31: class MachineOperatorBuilder; This is unused now and should be removed.
The CQ bit was checked by ivica.bogosavljevic@imgtec.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
LGTM, thanks!
The CQ bit was checked by ivica.bogosavljevic@imgtec.com
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 80001, "attempt_start_ts": 1496649469108930,
"parent_rev": "65c36c5cd49654dc3e8c8b5c32b31f0ce61ec013", "commit_rev":
"656c6d5eeae0048863bd18007231c07b48b5a9b5"}
Message was sent while issue was closed.
Description was changed from ========== MIPS[64]: Reland of `Fix unaligned arguments storage in Wasm-to-interpreter entry` Reland 84ff6e4c1997b63c01e95504c31ee6c5504430d5 In Wasm-to-interpeter entry creation, arguments for the interpreter are stored in an argument buffer. Depending on the order of the arguments some arguments may be misaligned and this causes crashes on those architectures that do not support unaligned memory access. TEST=mjsunit/wasm/interpreter BUG= ========== to ========== MIPS[64]: Reland of `Fix unaligned arguments storage in Wasm-to-interpreter entry` Reland 84ff6e4c1997b63c01e95504c31ee6c5504430d5 In Wasm-to-interpeter entry creation, arguments for the interpreter are stored in an argument buffer. Depending on the order of the arguments some arguments may be misaligned and this causes crashes on those architectures that do not support unaligned memory access. TEST=mjsunit/wasm/interpreter BUG= Review-Url: https://codereview.chromium.org/2887053003 Cr-Commit-Position: refs/heads/master@{#45703} Committed: https://chromium.googlesource.com/v8/v8/+/656c6d5eeae0048863bd18007231c07b48b... ==========
Message was sent while issue was closed.
Committed patchset #5 (id:80001) as https://chromium.googlesource.com/v8/v8/+/656c6d5eeae0048863bd18007231c07b48b... |
