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

[James E Wilson <wilson at specifixinc dot com>]

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 vax.md 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, http://www.SpecifixInc.com