Wilco Dijkstra writes:
> Hi Richard,
>
>> That's because, once an instruction matches, the instruction should
>> continue to match. It should always be possible to set the INSN_CODE of
>> an existing instruction to -1, rerun recog, and get the same instruction
>> code back.
>>
>> Because of that,
Hi Richard,
> That's because, once an instruction matches, the instruction should
> continue to match. It should always be possible to set the INSN_CODE of
> an existing instruction to -1, rerun recog, and get the same instruction
> code back.
>
> Because of that, insn conditions shouldn't depend
Wilco Dijkstra writes:
> Hi Richard,
>
>> It's ok for instructions to require properties that are false during
>> early RTL passes and then transition to true. But they can't require
>> properties that go from true to false, since that would mean that
>> existing instructions become unrecognisabl
Hi Richard,
> It's ok for instructions to require properties that are false during
> early RTL passes and then transition to true. But they can't require
> properties that go from true to false, since that would mean that
> existing instructions become unrecognisable at certain points during
> th
Wilco Dijkstra writes:
> The IRA combine_and_move pass runs if the scheduler is disabled and
> aggressively
> combines moves. The movsf/df patterns allow all FP immediates since they rely
> on a split pattern. However splits do not happen during IRA, so the result is
> extra literal loads. To
The IRA combine_and_move pass runs if the scheduler is disabled and aggressively
combines moves. The movsf/df patterns allow all FP immediates since they rely
on a split pattern. However splits do not happen during IRA, so the result is
extra literal loads. To avoid this, use a more accurate ch
