Re: [PATCH 1/4] regcprop: Avoid REG_CFA_REGISTER notes (PR85645)

2018-08-10 Thread Jeff Law
On 08/10/2018 02:55 PM, Segher Boessenkool wrote:
> On Mon, Jun 25, 2018 at 03:34:26PM -0600, Jeff Law wrote:
>> On 06/25/2018 05:53 AM, Segher Boessenkool wrote:
>>> Hi Eric,
>>>
>>> On Wed, May 09, 2018 at 09:22:47AM +0200, Eric Botcazou wrote:
> 2018-05-08  Segher Boessenkool  
>
>   PR rtl-optimization/85645
>   *  regcprop.c (copyprop_hardreg_forward_1): Don't propagate into an
>   insn that has a REG_CFA_REGISTER note.

 OK, thanks.
>>>
>>> Are these patches okay for backport to 8?  At least the first two.
>> Yes.
> 
> And for 7?  (Same two).
Yes.
jeff


Re: [PATCH 1/4] regcprop: Avoid REG_CFA_REGISTER notes (PR85645)

2018-08-10 Thread Segher Boessenkool
On Mon, Jun 25, 2018 at 03:34:26PM -0600, Jeff Law wrote:
> On 06/25/2018 05:53 AM, Segher Boessenkool wrote:
> > Hi Eric,
> > 
> > On Wed, May 09, 2018 at 09:22:47AM +0200, Eric Botcazou wrote:
> >>> 2018-05-08  Segher Boessenkool  
> >>>
> >>>   PR rtl-optimization/85645
> >>>   *  regcprop.c (copyprop_hardreg_forward_1): Don't propagate into an
> >>>   insn that has a REG_CFA_REGISTER note.
> >>
> >> OK, thanks.
> > 
> > Are these patches okay for backport to 8?  At least the first two.
> Yes.

And for 7?  (Same two).


Segher


Re: [PATCH 1/4] regcprop: Avoid REG_CFA_REGISTER notes (PR85645)

2018-06-25 Thread Jeff Law
On 06/25/2018 05:53 AM, Segher Boessenkool wrote:
> Hi Eric,
> 
> On Wed, May 09, 2018 at 09:22:47AM +0200, Eric Botcazou wrote:
>>> 2018-05-08  Segher Boessenkool  
>>>
>>> PR rtl-optimization/85645
>>> *  regcprop.c (copyprop_hardreg_forward_1): Don't propagate into an
>>> insn that has a REG_CFA_REGISTER note.
>>
>> OK, thanks.
> 
> Are these patches okay for backport to 8?  At least the first two.
Yes.
jeff


Re: [PATCH 1/4] regcprop: Avoid REG_CFA_REGISTER notes (PR85645)

2018-06-25 Thread Eric Botcazou
> Are these patches okay for backport to 8?  At least the first two.

If they fulfill the criteria for a release branch, no objection by me.

-- 
Eric Botcazou


Re: [PATCH 1/4] regcprop: Avoid REG_CFA_REGISTER notes (PR85645)

2018-06-25 Thread Segher Boessenkool
Hi Eric,

On Wed, May 09, 2018 at 09:22:47AM +0200, Eric Botcazou wrote:
> > 2018-05-08  Segher Boessenkool  
> > 
> > PR rtl-optimization/85645
> > *  regcprop.c (copyprop_hardreg_forward_1): Don't propagate into an
> > insn that has a REG_CFA_REGISTER note.
> 
> OK, thanks.

Are these patches okay for backport to 8?  At least the first two.


Segher


Re: [PATCH 1/4] regcprop: Avoid REG_CFA_REGISTER notes (PR85645)

2018-05-09 Thread Eric Botcazou
> 2018-05-08  Segher Boessenkool  
> 
>   PR rtl-optimization/85645
>   *  regcprop.c (copyprop_hardreg_forward_1): Don't propagate into an
>   insn that has a REG_CFA_REGISTER note.

OK, thanks.

-- 
Eric Botcazou


[PATCH 1/4] regcprop: Avoid REG_CFA_REGISTER notes (PR85645)

2018-05-08 Thread Segher Boessenkool
Changing a SET that has a REG_CFA_REGISTER note is wrong if we are
changing the SET_DEST, or if the REG_CFA_REGISTER has nil as its
argument, and maybe some other cases.  It's never really useful to
propagate into such an instruction, so let's just bail whenever we
see such a note.

Bootstrapped and tested on powerpc64-linux {-m32,-m64}.  Is this
okay for trunk?


Segher


2018-05-08  Segher Boessenkool  

PR rtl-optimization/85645
*  regcprop.c (copyprop_hardreg_forward_1): Don't propagate into an
insn that has a REG_CFA_REGISTER note.

---
 gcc/regcprop.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/regcprop.c b/gcc/regcprop.c
index a664f76..1813242 100644
--- a/gcc/regcprop.c
+++ b/gcc/regcprop.c
@@ -848,6 +848,12 @@ copyprop_hardreg_forward_1 (basic_block bb, struct 
value_data *vd)
  && reg_overlap_mentioned_p (XEXP (link, 0), SET_SRC (set)))
set = NULL;
}
+
+ /* We need to keep CFI info correct, and the same on all paths,
+so we cannot normally replace the registers REG_CFA_REGISTER
+refers to.  Bail.  */
+ if (REG_NOTE_KIND (link) == REG_CFA_REGISTER)
+   goto did_replacement;
}
 
   /* Special-case plain move instructions, since we may well
-- 
1.8.3.1