This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Which is better? More and simplier patterns? Fewer patterns with more embedded code?

Matt Thomas wrote:
I like the more and simplier patterns approach but I'm wondering what
the general recommendation is?

If an optimization pass will re-recog after rewriting an insn, then it is OK to have two separate patterns for two separate assembly insns. Otherwise, the optimization pass will miss valid optimizations, and you will get less than optimal code.

Essentially, all optimizations passes will re-recog, except for reload, which can't. Thus it is important that anything that might be related via reloads occur in the same pattern. So adding two registers and adding a register and a constant should be the same pattern, even if they are different assembly instructions, to get the best code. If they are different patterns, you will get less than optimal code from reload.

There is a restriction here that move pattern must contain all possible alternatives that can be generated by reload. If they don't, then reload will fail hard instead of just generating non-optimal code. This is because we reload insns by emitting move insns to fix them, but this doesn't work for a move insn itself, so they have to be fixed in place, which makes it mandatory that they support all possible alternatives.

So the question of whether to use one or two patterns depends on whether it will matter to reload. You didn't give details, so it is hard to comment on your specific example. Looking at the file, I think you are talking about making pushal and moval into two patterns instead of one. I suspect this will matter to reload, but offhand I can not be sure. You could try experimenting to check.

FYI If you compile with -dp, then the assembly code will have comments containing the pattern name and the alternative number. That solves the problem you were trying to fix by splitting apart patterns.
Jim Wilson, GNU Tools Support,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]