[PATCH] cmpelim: recognize extra clobbers in insns

Richard Sandiford richard.sandiford@arm.com
Fri Aug 21 10:05:18 GMT 2020


Pip Cet <pipcet@gmail.com> writes:
>> Pip Cet via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>> > I'm working on the AVR cc0 -> CCmode conversion (bug#92729). One
>> > problem is that the cmpelim pass is currently very strict in requiring
>> > insns of the form
>> >
>> > (parallel [(set (reg:SI) (op:SI ... ...))
>> >            (clobber (reg:CC REG_CC))])
>> >
>> > when in fact AVR's insns often have the form
>> >
>> > (parallel [(set (reg:SI) (op:SI ... ...))
>> >            (clobber (scratch:QI))
>> >            (clobber (reg:CC REG_CC))])
>> >
>> > The attached patch relaxes checks in the cmpelim code to recognize
>> > such insns, and makes it attempt to recognize
>> >
>> > (parallel [(set (reg:CC REG_CC) (compare:CC ... ...))
>> >            (set (reg:SI (op:SI ... ...)))
>> >        (clobber (scratch:QI))])
>> >
>> > as a new insn for that example. This appears to work.
>>
>> The idea looks good.  However, I think it'd be better (or at least
>> more usual) for the define_insns to list the clobbers the other
>> way around:
>>
>> (parallel [(set (reg:SI) (op:SI ... ...))
>>            (clobber (reg:CC REG_CC))
>>            (clobber (scratch:QI))])
>
> That makes sense, thanks for the suggestion. I realized quite quickly
> that I would have to reproduce the patterns precisely, including order
> in a parallel, and decided to go with the wrong consistent option by
> always placing the CC clobber last.
>
> My question is whether it makes more sense to recognize either form
> (i.e. a clobber of targetm.flags_regnum at any position in a parallel)
> or whether it's okay to assume that the clobber is always the second
> element in the parallel. I'm leaning towards the latter version.

Yeah, I agree the latter sounds best.  We should be able to test whether
the rest of the parallel is suitable by adding a single_set test
(after testing everything else).

Thanks,
Richard


More information about the Gcc-patches mailing list