[llvm-dev] Running GlobaISel passes after SelectionDAG instruction selection

[Gerolf Hoflehner via llvm-dev]

> On Nov 10, 2016, at 8:09 AM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Tue, Nov 08, 2016 at 04:54:42PM -0800, Quentin Colombet wrote:
>> Hi Tom,
>> 
>> 
>>> On Nov 7, 2016, at 9:28 AM, Tom Stellard <tom at stellard.net> wrote:
>>> 
>>> Hi,
>>> 
>>> I've been experimenting with global isel over the last few weeks and it
>>> is such a vast improvement over the SelectionDAG for the AMDGPU target
>>> that I would really like to begin using it as soon as possible.
>>> 
>>> Given the lack of a replacement for SelectionDAG's legalizer / combiner,
>> 
>> Could you elaborate on what is missing for the legalizer?
>> As always, we welcome contribution or PR to help guide the development of the framework.
>> 
>> And yeah, the combiner part is missing :).
>> 
> 
> I probably shouldn't have grouped the two together, but I' was mostly
> thinking about the combiner.  I haven't had much chance to look at the
> legalizer yet.
> 
>>> and how much work this will be to implement, I think the fastest path to
>>> doing this would be to run some of the GlobalISel passes after SelectionDAG
>>> instruction selection.
>>> 
>>> What I would like to do is modify the AMDGPU target to select SelectionDAG
>>> nodes to generic opcodes, and then run the InstructionSelector pass on
>>> the resulting MachineFunction.
>>> 
>>> I would start by doing this with loads/stores and then move on to other
>>> opcodes one at a time.
>>> 
>>> These changes will be a big improvement to AMDGPU, because it will allow
>>> us to replace our SIFixSGPRCopies pass which is essentially just another
>>> instruction selector that re-selects instructions based on their register
>>> classes and also let us do a much better job of matching addressing modes,
>>> which is very important for the AMDGPU target.
>>> 
>>> I already have a working prototype where I run SelectionDAG ISel and
>>> then the InstructionSelector pass right afterwards, but I think to
>>> make this approach work long-term,
>> 
>> When you say long-term what do you have in mind?
>> Put differently, I would recommend you help improving the framework instead of having this a supported solution. Indeed, the plan is still to kill SDISel :).
>> 
> 
> long-term means until we can switch to global-isel exclusively.
> 
> I'm really just looking for a way to speed our work on global-isel.  My
> proposal gives me a way to work on global-isel and certain improvements
> to our existing backend in parallel.  Otherwise, the global-isel work
> would have to be given lower priority.
There is still plenty of work in getting the framework ready to replace FastIsel by default on Aarch64. IMHO it makes more sense to revisit this in a few months.
> 
> But this is really more of a project planning problem than a technical
> issue.  I don't want to force a bad technical solution on the community
> if people don't think it's useful.
> 
> -Tom
> 
> 
>> Right now, we are not investing a lot of ressources into the investigation of how do we do combines. If you are interested in that aspect, let me know I will share my vision on those.
>> 
>> Cheers,
>> -Quentin
>> 
>>> we will need to agree that this is a
>>> supported use case of GlobalISel, and we will also need to start
>>> building the GlobalISel code by default.
>>> 
>>> What do people think about this?
>>> 
>>> Thanks,
>>> Tom
>> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev