[llvm-dev] GlobalISel: Very limited pattern matching?

[Quentin Colombet via llvm-dev]

> On May 20, 2019, at 11:19 AM, alex.davies at iinet.net.au wrote:
> 
> Hi Quentin,
> 
> Thank you for the peace of mind, it was really hard to know I hadn't missed an "EnableConstantFolding=1" line somewhere.
> 
> I'll apply a dirty hack at my end to make it work - there's quite a bit of legalization on this target.
> 
> Another quick one if I may. Is there a better Legalizer-like pass for reducing constant ranges? I find if I have a call at the top of a single-basic-block function, the register allocator will use every single callee-saved reg to store constants across the function call necessitating a heap of spilling. I note the Legalizer is described as only really being useful on allocators that do not rematerialize, but none of the register allocators I've tried seem to attempt to reduce callee-saved-spilling by narrowing constant ranges. The Legalizer itself also does not move within the same basic block, so it does nothing to prevent this problem either

There is the localizer (lib/CodeGen/GlobalISel/Localizer.cpp) that was specifically designed to paper over the limitations of the allocators, but we should definitely come up with a better strategy!
In the meantime, you can add this pass in your pipeline and hopefully you’ll get what you want :)

> 
> Missing a pass/setting, or is this for future improvement?
> 
> Cheers!
> 
> ----- Original Message -----
> From:
> "Quentin Colombet" <qcolombet at apple.com>
> 
> To:
> <alex.davies at iinet.net.au>
> Cc:
> "llvm-dev" <llvm-dev at listsllvm.org>, "Daniel Sanders" <daniel_l_sanders at apple.com>, "Amara Emerson" <aemerson at apple.com>, "Matt Arsenault" <arsenm2 at gmail.com>, "Aditya Nandakumar" <aditya_nandakumar at apple.com>, "Volkan Keles" <vkeles at apple.com>, "Jessica Paquette" <jpaquette at apple.com>
> Sent:
> Mon, 20 May 2019 10:04:56 -0700
> Subject:
> Re: [llvm-dev] GlobalISel: Very limited pattern matching?
> 
> 
> +gisel folks
> 
> Hi Alex,
> 
> You’re doing the right thing.
> That’s a known limitation that we’ve discussed in https://reviews.llvm.org/D59227 <https://reviews.llvm.org/D59227> but we didn’t really reach a conclusion back them.
> Short term, I believe you’re right, we should patch up the GISel emitter to use getConstantVRegVal instead of looking directly for G_CONSTANT.
> 
> Long term, this is something we need to discuss I personally think that we shouldn’t consider G_CONSTANT as true instructions and we should always extend them in place, but this is not a generally belief.
> 
> Cheers,
> -Quentin
> 
> On May 20, 2019, at 5:49 AM, via llvm-dev <llvm-dev at lists.llvmorg <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> Hi all,
> 
> I'm trying to get GlobalISel up and running on an off-tree architecture and am thinking I must be doing something wrong, given by how few things actually work.
> 
> Namely, any ImmLeaf<> pattern will fail to match if there is a (TRUNC/ZEXT/SEXT) applied to the constant operand, all of which are commonly created through Legalization. This is due to G_CONSTANT being explicitly looked for by the tablegened code, rather than code that makes use of getConstantVRegVal.
> 
> Is there supposed to be a constant folding pass before Instruction Selection? CSE does not fold past unaries applied to operands, I'm surely missing a pass somewhere...
> 
> Thanks,
> - Alex Davies
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190520/e73a28d1/attachment.html>