Open zl-wang opened 7 years ago
Can we get all of the explanation in this issue into the commit message? It's the kind of of 'change associated documentation' that IMO really belongs in the commit message where it has the best chance of providing value to the future.
hmm ... i was given the guideline: putting the detailed information in the Issue, and leaving the commit message brief. that was why i did here.
I'd like to open an issue to change that advice where you'd read it. IMO, putting all this info is covered in today's CONTRIBUTING.md under the following para:
Include as much information in your commit as possible. You may want to include designs and rationale, examples and code, or issues and next steps. Prefer copying resources into the body of the commit over providing external links. Structure large commit messages with markdown headers.
However, I know this hasn't always been how that section looked, so there may be out of date information hanging around somewhere.
Obviously JIT pseudo-TOC is mixed up with JIT-module system TOC.
I saw the implementation of retoreTOCRegister in omr/compiler/p/codegen/OMRTreeEvaluator.cpp. It is blind in the sense that we don't try to form dynamic code into an ABI-conforming module and the restored thing can be garbage.
It is an overkill to query if we are forming a module thus needing to restore system-TOC upon returning from call-out, when there is no codegen infrastructure to form a module anyhow (linker etc). plus, the current codegen is quite some distance from being optimal for module-style dispatch (i.e. glink code to share branch prediction resource).
Temporary fix before native calls can pass the callee descriptor instead of function address.