Add basic functionality to support call lowering for X86.
Currently only supports functions which return void and take zero arguments.
Inspired by commit 286573.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Picking this one (but the same applies to the ARM global isel skeleton commit).
I'm a little bit concerned to see various targets moving to global isel without proper scrutiny, as already pointed out by @echristo on llvm-dev. Don't get me wrong, I'm personally very excited about the whole idea, and it's likely that my organization will put some resources on it in the foreseeable future, but I would be less worried if Eric's concerns are addressed before moving forward.
I believe that @echristo's concern was about running in a mixed mode of existing ISel (SelectionDAG) and Global ISel, but better let him speak for himself.
At the moment I am not aware of plans to run the X86 ISel in such a mixed mode. This patch is intended to jumpstart implemention of the X86 part of the Global Isel as designed by the team lead by Quentin and in par with the documentation. The development team presented the current status of the work on Global ISel at the recent dev meeting, and called out to developers of other targets to join this effort. We agreed that we could start development of the X86 part in low gear and speed-up after some additional work will be completed, mainly related to tablegen uses.
Picking this one (but the same applies to the ARM global isel skeleton commit).
I'm a little bit concerned to see various targets moving to global isel without proper scrutiny, as already pointed out by @echristo on llvm-dev. Don't get me wrong, I'm personally very excited about the whole idea, and it's likely that my organization will put some resources on it in the foreseeable future, but I would be less worried if Eric's concerns are addressed before moving forward.
OK, I apologize if I missed the whole plan. So, is the goal that of growing this prototype into something ready for production? I remember there were some aspects that, although valuable, were voluntarily ignored for the prototype timeframe because there wasn't enough time (e.g. reuse of instcombine for the new selector).
I'm pretty sure there are others (which I don't have off the top of my head).
Are these aspects being reconsidered now (out of curiosity)?
It's really hard for me to see how this works without a more useful/completed implementation. It's also very under-specified at this time.
lib/Target/X86/X86CallLowering.cpp | ||
---|---|---|
30–39 ↗ | (On Diff #77752) | I'm interested in this bit -- how will a return be lowered? i.e. what will call this function, and will it happen for any instruction that counts as a return? |
lib/Target/X86/X86CallLowering.h | ||
32–33 ↗ | (On Diff #77752) | I may be missing something obvious, but why does call lowering need to lower a return? I would have thought return-lowering might happen in function lowering. |
Frankly, I see no better way to give GlobalISel the scrutiny it requires than by starting to port backends to it. We just need to have the right mindset about it.
There is always a tradeoff though: it makes harder to change pieces of the design as you increase the number of client of a framework/API. So it has to be carefully planned. But the core devs of GlobalISel are the best people to evaluate this tradeoff!
lib/Target/X86/X86CallLowering.cpp | ||
---|---|---|
30–39 ↗ | (On Diff #77752) | This target hook is called by the IRTranslator to lower a LLVM IR 'ret' instruction to the target's preferred machine IR sequence. See IRTranslator::translateRet(). |
lib/Target/X86/X86CallLowering.h | ||
32–33 ↗ | (On Diff #77752) | The CallLowering interface is a target-hook for lowering both caller and calee -related constructs. This patch only implements the callee part. The caller-part (i.e. lowering call sites) will be added in the future. |
lib/Target/X86/X86CallLowering.h | ||
---|---|---|
32–33 ↗ | (On Diff #77752) | I think I'm still missing something but maybe this is because of my confusion in naming -- this class is named X86CallLowering but it's implementing the lowering of the return instruction and the formal arguments. Wouldn't the function-lowering specific ("callee-side") code be better in a class named more appropriately specifically for function-lowering? Because I might expect to see that code alongside stack adjustment and prologue/epilogue lowering of a function rather than for lowering "calls". Does that make sense? |
lib/Target/X86/X86CallLowering.h | ||
---|---|---|
32–33 ↗ | (On Diff #77752) | We are going off-topic, but i don't mind to continue this discussion if you find it useful.
This class also inherits empty overloads of a method named lowerCall(). A follow-up task is to override these methods.
If you haven't done this already, I suggest you read the documentation about the LLVM Codegen [http://llvm.org/docs/CodeGenerator.html], There you will see that in the codegen-scale the initial lowering of LLVM IR to Machine IR and prologue/epilogue insertion happen in different (and distant) stages. Just to give you perspective, Global ISel only intends to replace the "Instruction Selection" phase of the entire code-generation pipe. |
OK, I apologize if I missed the whole plan. So, is the goal that of growing this prototype into something ready for production? I remember there were some aspects that, although valuable, were voluntarily ignored for the prototype timeframe because there wasn't enough time (e.g. reuse of instcombine for the new selector).
I'm pretty sure there are others (which I don't have off the top of my head).
Are these aspects being reconsidered now (out of curiosity)?
No need to apologize - you should feel free to raise your concerns.
The questions in your last comment are about GlobalISel in general which I would prefer the core development team (which are also the reviewers) answer them. Perhaps open a thread in llvm-dev?
From a GlobalISel perspective this looks like the obvious minimal x86 stub.
I think Zvi said he might be experimenting with IRTranslator coverage at the conference, so I assume this is part of making sure that work can be used by anyone else with an interest.