On 2011-05-06, at 12:23 AM, chevalma@iro.umontreal.ca wrote:
we should first implement some generic code patching functionality in the IR and backend, which we can then use to implement this optimization as well as several others.
I'm not sure what you have in mind as a "generic code patching functionality in the IR". The problem is that code patching is very low level (in the end you have to write real machine instructions). You need to know the size of the machine instructions, because code patching overwrites existing machine instructions with new machine instructions.
That seems like a hard problem at the IR level. There would need to be a way to point to individual IR instructions and "write" new IR instructions. It is not obvious how to do that efficiently (one inefficient way is to modify the IR of the function, convert all of the function to machine code, and overwrite the whole function, but that has problems like variation of the address of return points... I wouldn't even call it code "patching").
On the other hand, code patching is easier to do if it is transparent to the IR. In other words, the back-end guarantees that the IR instructions in the code stream are faithfully converted to some machine code, and that machine code may be optimized with code patching as long as the semantics of the IR instructions are maintained. For example, a "jump to function in the global object" IR instruction could be initially implemented as a call to a handler that looks up the name of the function in the global object, and when it is found, the call to the handler is replaced by a direct jump to the function (of course this optimization needs to reverted to the original code when that global property is stored to). So the IR of a function stays the same, it is the implementation of the IR using machine instructions that changes.
Marc