[PATCH] Do not remove labels with LABEL_PRESERVE_P

Jeff Law law@redhat.com
Wed Sep 24 18:59:00 GMT 2014


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



More information about the Gcc-patches mailing list