Re: [PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834, take 3)

2016-11-07 Thread Richard Biener
On Mon, 7 Nov 2016, Jakub Jelinek wrote: > On Fri, Nov 04, 2016 at 08:07:37PM +0100, Richard Biener wrote: > > >If/once this is in, I'm planning to test/submit a patch adding > > > /* If one decl is known to be a function or label in a function and > > > the other is some kind of data, they

[PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834, take 3)

2016-11-07 Thread Jakub Jelinek
On Fri, Nov 04, 2016 at 08:07:37PM +0100, Richard Biener wrote: > >If/once this is in, I'm planning to test/submit a patch adding > > /* If one decl is known to be a function or label in a function and > > the other is some kind of data, they can't overlap. */ > > if ((TREE_CODE (exprx) ==

Re: [PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834, take 2)

2016-11-04 Thread Richard Biener
On November 4, 2016 5:27:11 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >On Wed, Nov 02, 2016 at 10:46:40AM +0100, Richard Biener wrote: >> Yeah, plus if a followup test would have disambiguated things (the >> dispatch to the tree oracle for example). > >After discussing this on

[PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834, take 2)

2016-11-04 Thread Jakub Jelinek
Hi! On Wed, Nov 02, 2016 at 10:46:40AM +0100, Richard Biener wrote: > Yeah, plus if a followup test would have disambiguated things (the > dispatch to the tree oracle for example). After discussing this on IRC that the dse.c and sched-deps.c (call (mem ...) ) changes are probably not safe, I'm

Re: [PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834)

2016-11-02 Thread Richard Biener
On Wed, 2 Nov 2016, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 10:34:15AM +0100, Richard Biener wrote: > > Ok, just looking at regex.c (I happen to have regex.i around) shows > > the first hit as > > > > #2 0x008d9914 in true_dependence_1 (mem=0x761ef360, > >

Re: [PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834)

2016-11-02 Thread Jakub Jelinek
On Wed, Nov 02, 2016 at 10:34:15AM +0100, Richard Biener wrote: > Ok, just looking at regex.c (I happen to have regex.i around) shows > the first hit as > > #2 0x008d9914 in true_dependence_1 (mem=0x761ef360, > mem_mode=DImode, mem_addr=0x76220cf0, x=0x76605060, >

Re: [PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834)

2016-11-02 Thread Richard Biener
On Wed, 2 Nov 2016, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 10:08:25AM +0100, Richard Biener wrote: > > On Mon, 31 Oct 2016, Jakub Jelinek wrote: > > > > > Hi! > > > > > > Some automatic VAR_DECLs don't get DECL_RTL set - e.g. if its SSA_NAMEs > > > expand to multiple rtls, then there is

Re: [PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834)

2016-11-02 Thread Jakub Jelinek
On Wed, Nov 02, 2016 at 10:08:25AM +0100, Richard Biener wrote: > On Mon, 31 Oct 2016, Jakub Jelinek wrote: > > > Hi! > > > > Some automatic VAR_DECLs don't get DECL_RTL set - e.g. if its SSA_NAMEs > > expand to multiple rtls, then there is not a single one that can be used. > > Using DECL_RTL

Re: [PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834)

2016-11-02 Thread Richard Biener
On Mon, 31 Oct 2016, Jakub Jelinek wrote: > Hi! > > Some automatic VAR_DECLs don't get DECL_RTL set - e.g. if its SSA_NAMEs > expand to multiple rtls, then there is not a single one that can be used. > Using DECL_RTL on such VAR_DECLs ICEs. > > I've tried to just return 0 in

[PATCH] Fix nonoverlapping_memrefs_p ICE (PR target/77834)

2016-10-31 Thread Jakub Jelinek
Hi! Some automatic VAR_DECLs don't get DECL_RTL set - e.g. if its SSA_NAMEs expand to multiple rtls, then there is not a single one that can be used. Using DECL_RTL on such VAR_DECLs ICEs. I've tried to just return 0 in nonoverlapping_memrefs_p if either DECL_RTL_SET_P (expr{x,y}) wasn't true,