When we do this we will need a way to get access a 32-bit FPR argument register.
Created attachment 292629 [details] Patch
Comment on attachment 292629 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=292629&action=review > Source/JavaScriptCore/ChangeLog:7 > + This should also say: This patch also fixes a bug in the call opcode where the arguments would be reversed.
Comment on attachment 292629 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=292629&action=review > Source/JavaScriptCore/wasm/WasmCallingConvention.h:137 > - if (returnType == B3::Void) > - return nullptr; > - > - patchpoint->resultConstraint = B3::ValueRep::reg(GPRInfo::returnValueGPR); > + switch (returnType) { > + case B3::Void: > + break; This is a difference in behavior not related to floating point. Previously, you return a nullptr for a Void returnType. Now, you return a non-null patchpoint pointer. Is this intentional?
Comment on attachment 292629 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=292629&action=review r=me >> Source/JavaScriptCore/ChangeLog:7 >> + > > This should also say: This patch also fixes a bug in the call opcode where the arguments would be reversed. Please add some text as to what you did to enable FP operations.
(In reply to comment #2) > Comment on attachment 292629 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=292629&action=review > > > Source/JavaScriptCore/ChangeLog:7 > > + > > This should also say: This patch also fixes a bug in the call opcode where > the arguments would be reversed. Oops, thanks. I was planning to comment "Is it ok changing the order of the args?" :)
Created attachment 292641 [details] Patch for landing
Comment on attachment 292641 [details] Patch for landing Clearing flags on attachment: 292641 Committed r207781: <http://trac.webkit.org/changeset/207781>
All reviewed patches have been landed. Closing bug.