llvm dev - May 2019 - [GlobalISel] Is there a way to assign higher or lower priority to patterns?

Hi all,

I have two GIComplexOperandMatchers, one that takes
[base(gpr)+offset(imm)], another that takes (global address inc
offset) directly. It's quite possible that I'm not doing things the
right way(tm) by having these, but they seem to be making the
transition easier.

However, because these patterns are look identical to the parser,
tablegen seems to give them both equal preference - yet in all
instances, the direct memory addressing variant ought be preferred
over the one that requires a pointer register. I'm 99% sure that
AddedComplexity is ignored by GlobalISel, and from quick look through
GlobalISelEmitter.cpp I cannot find any alternative. Preferably, such
an alternative would be applied to Operands, at that (maybe asking a
bit much).
Before I go about renaming things such that alphabetical ordering
gives me the results I want or hacking in a similar workaround, just
want to check... is there a method I've missed for preferencing one
pattern over another currently?
Thanks,Alex Davies
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190523/fccbfa6c/attachment.html>

Hi Alex,

I can't say I'm happy that this is the case* but the SelectionDAG
importer does honour AddedComplexity. When it's sorting the rules, the
complexity score that SelectionDAG would have used has precedence over the
priority that GlobalISel uses. I ended up having to give in on my opposition to
using the complexity scores after we had a very hard time resolving ordering
differences on an out of tree target that was using AddedComplexity a lot
(pretty much everywhere) to fix up SelectionDAG's scheme

*I dislike the way AddedComplexity tweaks an already dubious scoring system
using magic numbers.
> On May 22, 2019, at 09:21, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> 
> Hi all,
> 
> I have two GIComplexOperandMatchers, one that takes
[base(gpr)+offset(imm)], another that takes (global address inc offset)
directly. It's quite possible that I'm not doing things the right
way(tm) by having these, but they seem to be making the transition easier.
> 
> However, because these patterns are look identical to the parser, tablegen
seems to give them both equal preference - yet in all instances, the direct
memory addressing variant ought be preferred over the one that requires a
pointer register. I'm 99% sure that AddedComplexity is ignored by
GlobalISel, and from quick look through GlobalISelEmitter.cpp I cannot find any
alternative. Preferably, such an alternative would be applied to Operands, at
that (maybe asking a bit much).
> 
> Before I go about renaming things such that alphabetical ordering gives me
the results I want or hacking in a similar workaround, just want to check... is
there a method I've missed for preferencing one pattern over another
currently?
> 
> 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/20190522/6a3dea6c/attachment.html>