This is an archive of the discontinued LLVM Phabricator instance.

[X86][GlobalISel] Add minimal call lowering support to the IRTranslator
ClosedPublic

Authored by zvi on Nov 13 2016, 11:02 AM.

Details

Summary

Add basic functionality to support call lowering for X86.
Currently only supports functions which return void and take zero arguments.
Inspired by commit 286573.

Diff Detail

Repository
rL LLVM

Event Timeline

zvi updated this revision to Diff 77752.Nov 13 2016, 11:02 AM
zvi retitled this revision from to [X86][GlobalISel] Add minimal call lowering support to the IRTranslator.
zvi updated this object.
zvi added reviewers: t.p.northover, ab, qcolombet.
zvi set the repository for this revision to rL LLVM.
zvi added a subscriber: llvm-commits.

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.

zvi added a comment.Nov 13 2016, 1:05 PM

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.

In D26593#593922, @zvi wrote:

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.

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.

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.

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.

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.

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!

zvi added inline comments.Nov 14 2016, 4:18 AM
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.

dberris added inline comments.Nov 14 2016, 4:47 AM
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?

zvi added inline comments.Nov 14 2016, 7:46 AM
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 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?

This class also inherits empty overloads of a method named lowerCall(). A follow-up task is to override these methods.

Because I might expect to see that code alongside stack adjustment and prologue/epilogue lowering of a function rather than for lowering "calls".

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.

zvi added a comment.Nov 14 2016, 8:01 AM

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?

t.p.northover accepted this revision.Nov 14 2016, 3:59 PM
t.p.northover edited edge metadata.

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.

This revision is now accepted and ready to land.Nov 14 2016, 3:59 PM
zvi added a comment.Nov 14 2016, 10:14 PM

Thanks for the review, Tim.

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.

I was not me. It was Philip if I am not mistaken.

This revision was automatically updated to reflect the committed changes.