https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #32 from Pierre-Marie de Rodat <derodat at adacore dot com> ---
(In reply to Bernd Schmidt from comment #28)
> It is sufficient for OUT(3) to be all-zeros. And I don't think the
> LAST_CHANGE_AGE mechanism does anything to prevent it. Please try it
> out. I think you have to initialize your bitmaps correctly rather than
> rely on "visited".
Thank you very much for the reproducer: I confirm that the
LAST_CHANGE_AGE mechanism does not have the effect I thought. I just
updated my patch locally to initialize bitmaps to 1 for all registers
and thus remove the visited field: this fixes the issue you found.
> > (In reply to Bernd Schmidt from comment #14)
> > > I do have to say that I am still uncomfortable with changing RRE to
>
> I did not write this.
Indeed: Kenneth Zadeck said this in comment #20. I made a pasto, sorry
for that!
(In reply to Paolo Bonzini from comment #29)
> BTW, are you sure that
>
> + if (DF_REF_FLAGS_IS_SET (def,
> + DF_REF_PARTIAL | DF_REF_CONDITIONAL))
> + /* All partial or conditional def
> + seen are included in the gen set. */
> + bitmap_set_bit (gen, regno);
>
> ? I would have thought they don't belong in any set, and on the
> contrary I would have thought that may-clobber definitions count as
> kills.
For partial and conditional defs in the context of MIR:
* if the register was initialized, then it is still initialized
afterwards, whatever happens;
* if the register was uninitialized, then in the case of partial def
there will still be bits uninitialized and in the case of
conditional def it is possible that the instruction leaves the
register uninitialized: in both case there is a possibility to leave
part of the register uninitialized.
So I would agree with: they don't belong in any set.
While thinking about this, I also realized with REE in mind that since
we need a conservative computation for MIR, we must set KILL/clear GEN
for register refs with DF_REF_MAY_CLOBBER: it may leave the register
uninitialized.
(In reply to Paolo Bonzini from comment #31)
> Ah, I see now. I think you're right that the DF_REF_MUST_CLOBBER case
> should also clear GEN in df_live_bb_local_compute.
>
> However, regarding the "BTW" I am fairly sure now that
> df_live_bb_local_compute and the corresponding function for MIR should
> handle may-clobber and may-sets differently. If you think of
> may-clobber and may-set as a diamond-shaped CFG:
>
> […]
>
> Then at the join point you have an "OR" for LIVE (so the clobber's
> KILL disappears and the set's GEN remains), and an "AND" for MIR. For
> MIR the clobber's KILL remains and the set's GEN disappears.
Agreed, thank you! I have updated both MIR and LIVE in the light of
this. (bootstrapped and regtested on x86_64-linux)
