https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Bernd Schmidt <bernds at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bernds at gcc dot gnu.org
--- Comment #14 from Bernd Schmidt <bernds at gcc dot gnu.org> ---
I've looked at this for a while now. I agree that this is a bug in REE that
needs to be fixed in a manner similar to this patch. However, there are some
oddities here.
As you say, the df-live problem claims to compute a must-initialized problem,
so it would be very odd to add another problem with the same name. I
experimented with changing df_live_confluence_n to use and instead of ior,
followed by actually taking the confluence_n from your mir problem. However,
this does not work: ior enlarges the set while and shrinks it, so the
initialization of the bitmaps would have to be different. It looks like your
"visited" bit tries to avoid that, but I don't think this works. One testcase I
looked at had this structure:
entry -> 2 -> 3 -> 3
i.e. a loop in block 3. The confluence_n function takes the out bitmap from
block 3 (which is all zeros) and ands it with the in bitmap from the same
block, which has the incoming regs from block 2 at that point, but obviously
the bitmap turns into all zeros at this point (block 3 was already visited due
to the 2->3 edge). I don't see how your patch doesn't suffer from the same
problem.
I think ideally we would figure out whether df_live really does have a mistake
in it, and if so fix it rather than adding another problem.
