Jeff Law writes:
> On 08/06/2018 04:53 AM, Senthil Kumar Selvaraj wrote:
>> Ping!
>>
>> Regards
>> Senthil
>>
>> Senthil Kumar Selvaraj writes:
>>
>>> Hi,
>>>
>>> The below patch fixes an ICE for the avr target when the setmemhi
>>> expander is involved.
>>>
>>> The setmemhi expander generated RTL ends up as an unrecognized insn
>>> if the alignment of the destination exceeds that of a QI
>>> mode const_int (127), AND the number of bytes to set fits in a QI
>>> mode const_int. The second condition prevents *clrmemhi from matching,
>>> and *clrmemqi does not match because it expects operand 3 (the alignment
>>> const_int rtx) to be QI mode, and a value of 128 or greater does not fit.
>>>
>>> The patch fixes this by changing the *clrmemqi pattern to match a HI
>>> mode const_int, and also adds a testcase.
>>>
>>> Regression test showed no new failures, ok to commit to trunk?
>>>
>>> Regards
>>> Senthil
>>>
>>> gcc/ChangeLog:
>>>
>>> 2018-07-18 Senthil Kumar Selvaraj <senthilkumar.selva...@microchip.com>
>>>
>>> PR target/85624
>>> * config/avr/avr.md (*clrmemqi): Change mode of operands[2]
>>> from QI to HI.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2018-07-18 Senthil Kumar Selvaraj <senthilkumar.selva...@microchip.com>
>>>
>>> PR target/85624
>>> * gcc.target/avr/pr85624.c: New test.
> Given there's also pattern clrmemhi it feels like you're papering over a
> bug elsewhere, possibly in the expanders.
clrmemhi and clrmemqi differ on the mode of the register used to hold
the number of bytes to clear. The setmemhi expander picks a QI or HI
mode reg depending on the width of the size operand, and the
clrmem{qi,hi} match on that.
The operand whose mode I modified represents the alignment of the
destination, and isn't actually used in the assembler template.
Regards
Senthil
>
> Ultimately I'll leave the decision here to the AVR maintainers through.
>
> jeff
