Georg-Johann Lay schrieb:
> Richard Henderson schrieb:
>
>> Why are you adding "optimize" to all these insns? None of them will
>> be matched unless combine is run, which implies optimization.
>
> Here is a patch without optimize in the insn conditions.
>
> The optimize condition is still present in the insv expander because I
> do not know what the policy about that is in the avr backend.
>
> Johann
>
>> r~
>>
>
> PR target/42210
>
> * config/avr/predicates.md (const1_operand, const_0_to_7_operand):
> New predicates.
>
> * config/avr/avr.md ("insv"): New insn expander.
> ("*movbitqi.1-6.a", "*movbitqi.1-6.b", "*movbitqi.0", "*insv.io",
> "*insv.not.io", "*insv.reg"): New insns.
>
Patch:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02099.html
As Denis wrote in
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00081.html
some pattern are too hard to understand. Presumably that are the
patches that open-code some bit insertions.
Would the path, be ok without these patterns, namely without
"*movbitqi.1-6.a"
"*movbitqi.1-6.b"
"*movbitqi.0"
"*movbitqi.7"
A am still of the opinion that avr should make use of insn combine and
it's power. If these patterns are too hard to understand I can add
some more comments and explanations.
The insv-like patterns are plain vanilla
"insv"
"*insv.io"
"*insv.reg"
These patterns are likely on machines that come with bitfield
representations for SFRs. On targets where just SFR addresses and bit
positions are available, bit insertions and extractions are open coded
by bunch of or-and-not-mask arithmetic, so it's not unlikely to see
them in the insn stream. Moreover, RTL lowering won't use insv on
volatile mem, just combiner can do that magic. Without the patch there
are places where a long, slow 16-bit(!) shift is used requiring a
bulky slow loop.
If you sag what patterns are ok an which are not, I will make an
according patch. (Without combine bridges other patterns might be
dead, because combine doesn't look deep enough).
Johann
