2011/5/16 Georg-Johann Lay <a...@gjlay.de>:
> Denis Chertykov schrieb:
>> 2011/5/11 Georg-Johann Lay <a...@gjlay.de>:
>>> 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.
>>>>
>>>> May be somebody else have a different oppinion ?
>>>> I'm open to discussion.
>>>>
>>>> Denis.
>>> Let me add that the patch is generic enough to also improve ORing HI against
>>> QI like described in
>>>
>>> http://gcc.gnu.org/PR41076
>>>
>>> which is not uncommon on avr.
>>
>> You right here.
>> Please, apply the patch.
>
> Applied the current version of the patch:
>
> http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173792
>
> There are still situations that could be handled easily by avr like:
>
> [1]: Two instructions
> (set (reg:HI 50)
>     (ior:HI (ashift:HI (zero_extend:HI (reg:QI 52))
>                        (const_int 8))
>             (zero_extend:HI (reg:QI 55))))
>
> [2]: Two instructions
> (set (reg:HI 50)
>     (ior:HI (ashift:HI (reg:HI 51)
>                        (const_int))
>             (zero_extend:HI (reg:QI 55))))
>
> [3]: One Instruction
> (set (reg:HI 50)
>     (ior:HI (ashift:HI (reg:HI 51)
>                        (const_int 8))
>             (reg:HI 54)))
>
> If you agree, I make a patch to cover these cases, too. Just for HI,
> without mode iterators so that they are easier to understand.
>
> IMO it's preferred to do some pre-reload transforms instead of trying
> to catch such situations in peepholes or let the optimization
> opportunity pass by without making use of it.
>
> Unfortunately, there is no standard form the middle end tries; it
> differs depending on if a value is in memory or in a register and of
> -fsplit-wide-types is on or not.
>
> The patterns may seem complicated, but it's just what's going on...

Please, provide the patch.

Denis.

Reply via email to