Denis Chertykov schrieb:
> 2011/5/2 Georg-Johann Lay <a...@gjlay.de>:
>> This is a fix for an optimization flaw when a long value is composed
>> from byte values.
>>
>> For -fsplit-wide-types (which is still default for avr) the code is
>> worse than with -fno-split-wide-types. The code for the test case is
>> better in either situations, i.e. compared to code without the patch,
>> but it is still not optimal.
>>
>> Fixing this by some combine patterns is the only thing the BE can do.
>> I did not write more complex patterns because things get too complex
>> with little performance gain.
>>
>> Tested without regressions.
>>
>> Johann
>>
>> 2011-05-02 Georg-Johann Lay <a...@gjlay.de>
>>
>> PR target/27663
>> * config/avr/predicates.md (const_8_16_24_operand): New predicate.
>> * config/avr/avr.md ("*ior<mode>qi.byte0",
>> "*ior<mode>qi.byte1-3"): New define_insn_and_split patterns.
>>
>
> I'm sorry, but I dot'n like to have a both combiner related patches in
> port because code improvement isn't much and your patterns are
> difficult to understand and maintain.
You refer to this patch for PR42210?
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02099.html
> May be somebody else have a different oppinion ?
> I'm open to discussion.
The patterns in this patch are similar to "*addhi3_zero_extend",
"*addhi3_zero_extend1" that handle HI+QI resp. "*addhi3_zero_extend"
that handle SI+QI.
The difference is that they handle IOR instead of PLUS. It's true that
the user has to use some specific code (addition of QI to HI resp. SI
in the first case and ORing of QI to HI resp. SI in the second).
IMO insn combine is a very powerful pass and I do not see why the avr
BE should not take advantage of it to synthesize new instructions.
Note that other parts like "*sbi" or "*cbi" rely on insn combine, too.
If it's hard to understand what their intention is, I can add some
more comments.
As insn combine is capable of generating new instructions that are not
covered by standard patterns, it is only natural that they might be
more complicated than standard patterns. But almost everything in GCC
is complicated, even in the avr BE stuff like, e.g. handling of
rotate, is way much more complicated.
The new patterns are restricted to one single place in the backend.
If they are correct, they are supposed to work in the future without
steadily maintaining them.
I agree that it would be nice if the middleend detected the
expressions as, say, (set (zero_extract:QI (reg:SI ...))), but that's
not the case; not even on 32-bit targets with full insv/extzv support.
And as I already wrote, the -fsplit-wide-types is not a good choice on
avr (except for 64-bit stuff where subreg lowering leads to much
code), see
http://gcc.gnu.org/ml/gcc/2011-03/msg00261.html
So with -fno-split-wide-types and some more elaborate testcase you
will see that the new patterns are a clear improvement.
Johann
>
> Denis.
>
