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

[Daniel Sanders via llvm-dev]

> On May 20, 2019, at 11:19, via llvm-dev <llvm-dev at lists.llvm.org> 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
> 
> Missing a pass/setting, or is this for future improvement?

The constants being in the first block is part of a memory optimization to minimize the number of duplicate constants. The intent is that since matches can reach across blocks, they are effectively sunk by a successful match and hopefully end up dead as a result. If that doesn't happen then we'll rely on other MIR passes sinking them to sensible places. Off-hand, I'm not sure which pass normally does the sinking of the remaining constants. I think it's probably RegisterCoalescer or something along those lines

> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> 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/67378423/attachment.html>