As you know, I'm currently working on implementing a lower level IR subset and handler implementation so as to simplify the work the backend has to do in terms of code generation. One issue that caught my attention today is that the IR has both a call and a construct instruction. The construct instruction (used for constructor calls, with the new operator) implicitly creates a new object and binds it to the this value.
This is probably not the kind of work we want to have the backend do, because it won't know how to create a JS object on its own, so I thought that it would make sense to translate constructor calls into regular function calls, where I first create an object to use as the this value before the call, and check whether or not the function returned an object after the call, and if so, use that as the newly created object, instead of the one I created before the call.
One issue, however, is that while this should work for JavaScript code, as far as I understand the ECMA spec (feel free to double check), we may still want to know which calls really are object constructions, because if we end up calling native C/C++ code (eg: browser DOM), it may expect us to tell it what is a constructor call, as opposed to a regular function call.
The current solutions I have in mind are either:
1) Keep the construct instruction separate from call, but have it take an explicit this pointer, just like call.
2) Get rid of the construct instruction, and instead have a flag (eg: isConstruct) on the call instruction.
I'm personally more in favor of the first one, because it avoids special-casing the call instruction in various places. Which one would you guys vote for?
- Maxime