Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> On Tue, Feb 16, 2021 at 09:55:40AM +0000, Richard Sandiford wrote:
>> I assume that's because pass_df_initialize_no_opt is slightly after
>> the first pass_split_all_insns? Seems like it should just be a case
>> of moving it up.
>>
>> > And for noflow where the cfg doesn't really exit I wouldn't even attempt to
>> > do df_analyze.
>>
>> What stops ix86_ok_to_clobber_flags being called in that case?
>
> split5 is never enabled on i386.
> virtual bool gate (function *)
> {
> /* The placement of the splitting that we do for shorten_branches
> depends on whether regstack is used by the target or not. */
> #if HAVE_ATTR_length && !defined (STACK_REGS)
> return true;
> #else
> return false;
> #endif
> }
OK. I guess not running df_analyze in that pass is “safe” because any
attempt to use DF should hopefully blow up spectacularly.
But following up from what we discussed on IRC, could the splits in
question use define_peephole2 instead? There's an example in the docs
of using it for one instruction (plus one scratch register):
@smallexample
(define_peephole2
[(match_scratch:SI 2 "r")
(parallel [(set (match_operand:SI 0 "register_operand" "")
(match_operator:SI 3 "arith_or_logical_operator"
[(match_dup 0)
(match_operand:SI 1 "memory_operand" "")]))
(clobber (reg:CC 17))])]
"! optimize_size && ! TARGET_READ_MODIFY"
[(set (match_dup 2) (match_dup 1))
(parallel [(set (match_dup 0)
(match_op_dup 3 [(match_dup 0) (match_dup 2)]))
(clobber (reg:CC 17))])]
"")
@end smallexample
In this case the match_scratch wouldn't work, since CC_REGNUM is fixed.
But as you said on irc, there's peep2_regno_dead_p instead.
Haven't tried it and so don't know whether it would work with only
one construct in the first […]. But it seems like it would be a better
fit, since peephole2 is designed to have up-to-date register information.
Uros, does that sound reasonable, or is it a non-starter?
Thanks,
Richard
