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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Tsur Herman via llvm-dev
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Tsur Herman 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 <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev