This is the mail archive of the gcc@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: Question on missed insn combine optimization.


Bernd Schmidt wrote:
> On 07/12/11 13:11, Georg-Johann Lay wrote:
>> Not familiar with combine inerts, I'd like to know if
>> it's low hanging fruit to teach insn combine to perform
>> optimizations like the following.
>>
>> Suppose following C code, int = HI
>>
>> int y15;
>> int x15;
>>
>> void qmul8_xy (char c, int x, int y)
>> {
>>     y15 = y * c;
>>     x15 = x * c;
>> }
>>
>> and that the target has an insn like
>>
>> (set (reg:HI)
>>      (mult:HI (sign_extend:HI (reg:QI))
>>               (reg:HI)))
>>
>> If there was just one multiplication, combine would
>> combine the sign_extend into the special mul insn.
>> (Provided costs are advantageous, of course)
>>
>> However, with the code example from above, combine
>> won't insert the sign_extend even if it was an
>> improvement, i.e. the sign_extend does not disappear
>> but the special mult is cheaper (or same cost) as the
>> ordinary mult.
>>
>> The original RTL reads:
>>
>> == Stage 0 ==
>>
>> (set (reg:HI 42)
>>      (sign_extend:HI (reg:QI 24)))
>>
>> (set (reg:HI 48)
>>      (mult:HI (reg:HI 42)
>>               (reg:HI 47)))
>>
>> (set (reg:HI 49)
>>      (mult:HI (reg:HI 42)
>>               (reg:HI 46)))
>>
>> == Stage 1 ==
>>
>> Cheaper than Stage 0 but not performed
>>
>> (set (reg:HI 42)
>>      (sign_extend:HI (reg:QI 24)))
>>
>> (set (reg:HI 48)
>>      (mult:HI (sign_extend:HI (reg:QI 24))
>>               (reg:HI 47)))
>>
>> (set (reg:HI 49)
>>      (mult:HI (reg:HI 42)
>>               (reg:HI 46)))
>>
>> == Stage 2 ==
>>
>> Cheaper than Stage 0 and Stage 1, would be performed
>> if we had Stage 1.
>>
>> (set (reg:HI 48)
>>      (mult:HI (sign_extend:HI (reg:QI 24))
>>               (reg:HI 47)))
>>
>> (set (reg:HI 49)
>>      (mult:HI (sign_extend:HI (reg:QI 24))
>>               (reg:HI 46)))
> 
> You could try the following, which allows 2->2 insn combinations
> assuming the costs are right.
> 
> Bernd

The patch leads to wrong code:
The extend is inserted into the first mul-insn and the extend
discarded so that the second mul which remains unchanged gets garbage
for one of its inputs.

Johann


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