Fix inconsistent return type use in BaseCompiler::emitInstanceCall

RESOLVED FIXED in Firefox 67

Status

()

enhancement
RESOLVED FIXED
6 months ago
6 months ago

People

(Reporter: jseward, Assigned: jseward)

Tracking

unspecified
mozilla67
Points:
---

Firefox Tracking Flags

(firefox67 fixed)

Details

Attachments

(1 attachment)

emitInstanceCall() generates code to call a SymbolicAddress:: builtin. One of
the parameters to emitInstanceCall() is the ABI-level return type of the call.
If that is non-void, the returned value is pushed on to the compiler's operand
stack.

There are some functions, for example Instance::memFill, which return a value
(an ExprType::I32) which is an implementation artefact, and which we don't
want to push on the operand stack. As it stands, in such cases we lie to
emitInstanceCall() by telling it the return type is ExprType::Void, so as to
stop it pushing the return value. This inconsistency is confusing, and more
importantly it gets in the way of ongoing work to move towards having
single-point-of-truth definitions of argument and result types for
SymbolicAddress:: builtin functions.

Assignee: nobody → jseward
Attachment #9044187 - Flags: review?(lhansen)
Comment on attachment 9044187 [details] [diff] [review]
bug1528240-inconsistent-ret-tys-baseline-1.diff

Review of attachment 9044187 [details] [diff] [review]:
-----------------------------------------------------------------

Nice and clean.
Attachment #9044187 - Flags: review?(lhansen) → review+
Pushed by jseward@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/55806c7e28b7
Fix inconsistent return type use in BaseCompiler::emitInstanceCall.  r=lhansen.
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.