On 09/24/14 03:30, Steven Bosscher wrote:
What appears to be the case here, is that you have a label between two
basic blocks B1 and B2, and the label acts as a control flow barrier:
B1 and B2 cannot be merged. Then this should be expressed in the CFG.
Otherwise: What else prevents the merge_blocks CFG hooks from deleting
the label?
A part of me wonders why we have the label at all. Can't we just use
dot-relative addressing.
But yes, exposing the PIC setup label is problematical in various ways.
We've gone a different direction in later patches, but the underlying
issues are worth continuing to dig into.
That means even if we do not have any usages
we shouldn't remove it.
Sorry, no.
Even a LABEL_PRESERVE_P label can be deleted: It will be replaced by a
NOTE_INSN_DELETED_LABEL. See cfgrtl.c:delete_insn().
If you really want to prevent a label from being deleted, then
LABEL_PRESERVE_P is not a sufficient condition.
Why can't we add some additional usages
later?
If you add the usages later, then you're lying to the compiler ;-)
Perhaps. The problem is while we can expose all the known uses early,
reload/LRA via rematerialization can create new ones, even after all the
old ones have gone away.
It's a not terribly uncommon problem for reload/LRA to generate new
symbolic references to objects when rematerializing certain constants.
Those new references will expose new uses of the PIC register and
consequently perhaps the PIC setup label.
This puts us in an interesting position WRT LABEL_PRESERVE_P.
Jeff
