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

Quentin Colombet via llvm-dev llvm-dev at lists.llvm.org
Mon May 20 10:04:56 PDT 2019


+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 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.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
> 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/8b0db034/attachment.html>


More information about the llvm-dev mailing list