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

via llvm-dev llvm-dev at lists.llvm.org
Mon May 20 11:19:49 PDT 2019


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?
Cheers!
__
----- Original Message -----
From: "Quentin Colombet" 
To:
Cc:"llvm-dev" , "Daniel Sanders" , "Amara Emerson" , "Matt Arsenault"
, "Aditya Nandakumar" , "Volkan Keles" , "Jessica Paquette" 
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 [1] 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  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 [3]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 

Links:
------
[1] https://reviews.llvm.org/D59227
[2] mailto:llvm-dev at lists.llvm.org
[3] mailto:llvm-dev at lists.llvm.org

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


More information about the llvm-dev mailing list