[PATCH] Do not remove labels with LABEL_PRESERVE_P

Jeff Law law@redhat.com
Tue Sep 23 16:06:00 GMT 2014


On 09/23/14 10:01, Steven Bosscher wrote:
> On Fri, Sep 19, 2014 at 10:03 PM, Jeff Law <law@redhat.com> wrote:
>> On 09/19/14 13:36, Ilya Enkovich wrote:
>>>
>>> Hi,
>>>
>>> During my work on enabling pseudo PIC register I've found that cfg cleaunp
>>> may remove lables with LABEL_PRESERVE_P set to 1.  In my case I generated
>>> SET_RIP during expand pass and cfg cleanup removed label it used as an
>>> operand.  Below is a patch that fixes it.  It is not actually required for
>>> our latest PIC related patch but still seems to make sense.
>>>
>>> Bootstrapped and tested on linux-x86_64.
>>>
>>> Thanks,
>>> Ilya
>>> --
>>> 2014-09-19  Ilya Enkovich  <ilya.enkovich@intel.com>
>>>
>>>          * cfgcleanup.c (try_optimize_cfg): Do not remove label
>>>          with LABEL_PRESERVE_P flag set.
>>
>> OK.  Please install.
>>
>> Note for those not following the x86 32 bit PIC register discussion, I asked
>> Ilya to submit this separately.  It was something an earlier version of his
>> patch triggered and it stood out as something that ought to be fixed
>> regardless of the final form of the PIC register changes that are in
>> progress.
>
> Jeff,
>
> Are you sure this patch is necessary, and is not just papering over
> another problem? In the past, all cases I've seen where labels were
> removed inadvertently were caused by incorrect reference counting or
> missing REG_LABEL_* notes.
>
> Did the label use count drop to zero? Is there a REG_LABEL_TARGET note
> for the label operand?
The way it was described to me is, yes, the label count dropped to zero. 
  In simplest terms, it was a single use label that was marked with 
LABEL_PRESERVE_P.  The combiner removed the last reference, then 
cfgcleanup came along and *boom*.

It was with some ongoing development work that's going in a slight 
different direction, so we don't have a testcase to include.

jeff



More information about the Gcc-patches mailing list