This is the mail archive of the gcc-patches@gcc.gnu.org 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: [Patch,AVR]: Fix PR27663


Denis Chertykov schrieb:
> 2011/5/11 Georg-Johann Lay <avr@gjlay.de>:
>> Denis Chertykov schrieb:
>>> 2011/5/2 Georg-Johann Lay <avr@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  <avr@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...

Johann

> 
> Denis.
> 


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