Re: [patch] Fix over-optimization of calls to pure function

2014-05-20 Thread Eric Botcazou
> DOM bits are good. Richi wants the "redundant" test to be kept around, > so OK with that change. Thanks. The test is more duplicated than redundant so I'll remove it anyway. -- Eric Botcazou

Re: [patch] Fix over-optimization of calls to pure function

2014-05-20 Thread Eric Botcazou
> Can't I have sometihng like > > loop (i as iterator) >begin > I := F(0); >exception > when E => N := N + 1; >end; > > here I would expect PRE to discover I as loop invariant that will cause > exception to be called just once, not at every iteration of loop? Yet the follo

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Jeff Law
On 05/19/14 02:58, Eric Botcazou wrote: Hi, this fixes an over-optimization of the GIMPLE optimizer, whereby two otherwise identical calls to a pure function present in different EH regions are CSEd, which changes the semantics of the program because the second EH handler is not invoked: beg

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Jan Hubicka
> Hi, > > this fixes an over-optimization of the GIMPLE optimizer, whereby two > otherwise > identical calls to a pure function present in different EH regions are CSEd, > which changes the semantics of the program because the second EH handler is > not invoked: > > begin > I := F(0); >

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Richard Biener
On Mon, May 19, 2014 at 12:11 PM, Eric Botcazou wrote: >> I thought we had decided a long time ago that pure and const functions could >> not throw and that was the documented behavior. > > No, it's precisely the opposite. Btw, I agree. For this and other attributes the behavior is that it speci

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Richard Biener
On Mon, May 19, 2014 at 12:21 PM, Eric Botcazou wrote: >> Please keep the "redundant" test, it speeds up comparison on hash >> collisions. As you are on it I'd use size_int (lr). > > The redundant test is very redundant, see the line just below it. Oh... ok ;) >> I think it's ok to CSE foo (0)

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Eric Botcazou
> Can either of you back that up with mailing list archive references? See https://gcc.gnu.org/ml/gcc-patches/2008-08/msg00043.html which points to a previous discussion in January. There are 2 tests in the gnat.dg testsuite: gnat.dg/handle_raise_from_pure.adb gnat.dg/test_raise_from_pure.ad

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Eric Botcazou
> Please keep the "redundant" test, it speeds up comparison on hash > collisions. As you are on it I'd use size_int (lr). The redundant test is very redundant, see the line just below it. > I think it's ok to CSE foo (0) for > >try { > foo (0); >} catch (...) { side-effect } >

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Jakub Jelinek
On Mon, May 19, 2014 at 12:11:25PM +0200, Eric Botcazou wrote: > > I thought we had decided a long time ago that pure and const functions could > > not throw and that was the documented behavior. > > No, it's precisely the opposite. Can either of you back that up with mailing list archive referen

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Eric Botcazou
> I thought we had decided a long time ago that pure and const functions could > not throw and that was the documented behavior. No, it's precisely the opposite. -- Eric Botcazou

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread pinskia
> On May 19, 2014, at 2:39 AM, Richard Biener > wrote: > >> On Mon, May 19, 2014 at 10:58 AM, Eric Botcazou >> wrote: >> Hi, >> >> this fixes an over-optimization of the GIMPLE optimizer, whereby two >> otherwise >> identical calls to a pure function present in different EH regions are CSE

Re: [patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Richard Biener
On Mon, May 19, 2014 at 10:58 AM, Eric Botcazou wrote: > Hi, > > this fixes an over-optimization of the GIMPLE optimizer, whereby two otherwise > identical calls to a pure function present in different EH regions are CSEd, > which changes the semantics of the program because the second EH handler

[patch] Fix over-optimization of calls to pure function

2014-05-19 Thread Eric Botcazou
Hi, this fixes an over-optimization of the GIMPLE optimizer, whereby two otherwise identical calls to a pure function present in different EH regions are CSEd, which changes the semantics of the program because the second EH handler is not invoked: begin I := F(0); exception when E