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

[Daniel Sanders via llvm-dev]

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>