Fix handling of indirect stackmap locations in FTL OSR exit
https://bugs.webkit.org/show_bug.cgi?id=122666
Reviewed by Mark Hahnenberg.
With this change, the llvm.webkit.stackmap-based OSR exit only fails one test, down from
five tests previously.
* ftl/FTLLocation.cpp:
(JSC::FTL::Location::gpr): It's OK to call this method when kind() == Indirect, so asserting that isGPR() is wrong; change to assert that involvesGPR().
(JSC::FTL::Location::restoreInto): Stack-related registers aren't saved to the scratch buffer, so use them directly.
* ftl/FTLLocation.h: Add comment about requirements for stack layout.
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStubWithOSRExitStackmap): Make enough room on the stack so that saveAllRegisters() has a scratchpad to save things to. Without this, saveAllRegisters() may clobber a spilled value.
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157326 268f45cc-cd09-0410-ab3c-d52691b4dbfc
diff --git a/Source/JavaScriptCore/ftl/FTLLocation.h b/Source/JavaScriptCore/ftl/FTLLocation.h
index 74fcf16..2ec22f3 100644
--- a/Source/JavaScriptCore/ftl/FTLLocation.h
+++ b/Source/JavaScriptCore/ftl/FTLLocation.h
@@ -155,7 +155,11 @@
// Assuming that all registers are saved to the savedRegisters buffer according
// to FTLSaveRestore convention, this loads the value into the given register.
- // The code that this generates isn't exactly super fast.
+ // The code that this generates isn't exactly super fast. This assumes that FP
+ // and SP contain the same values that they would have contained in the original
+ // frame. If we did push things onto the stack then probably we'll have to change
+ // the signature of this method to take a stack offset for stack-relative
+ // indirects.
void restoreInto(MacroAssembler&, char* savedRegisters, GPRReg result) const;
private:
