Jakub Jelinek wrote:
>On Thu, Jan 09, 2014 at 02:27:40PM +0100, Richard Biener wrote:
>> > Perhaps, if you don't like the !gimple_in_ssa_p (cfun) in the
>condition
>> > we can just drop the lhs always in that case, just doing what we do
>for
>> > __builtin_unreachable if lhs is SSA_NAME:
>> > tr
On Thu, Jan 09, 2014 at 02:27:40PM +0100, Richard Biener wrote:
> > Perhaps, if you don't like the !gimple_in_ssa_p (cfun) in the condition
> > we can just drop the lhs always in that case, just doing what we do for
> > __builtin_unreachable if lhs is SSA_NAME:
> > tree var = create_tmp_var (TREE
On Thu, 9 Jan 2014, Jakub Jelinek wrote:
> On Thu, Jan 09, 2014 at 02:13:39PM +0100, Richard Biener wrote:
> > On Thu, 9 Jan 2014, Jakub Jelinek wrote:
> >
> > > On Thu, Jan 09, 2014 at 01:30:53PM +0100, Richard Biener wrote:
> > > > > gimplify_modify_expr has:
> > > > >
> > > > > if (!gim
On Thu, Jan 09, 2014 at 02:13:39PM +0100, Richard Biener wrote:
> On Thu, 9 Jan 2014, Jakub Jelinek wrote:
>
> > On Thu, Jan 09, 2014 at 01:30:53PM +0100, Richard Biener wrote:
> > > > gimplify_modify_expr has:
> > > >
> > > > if (!gimple_call_noreturn_p (assign))
> > > > gimple_cal
On Thu, 9 Jan 2014, Jakub Jelinek wrote:
> On Thu, Jan 09, 2014 at 01:30:53PM +0100, Richard Biener wrote:
> > > gimplify_modify_expr has:
> > >
> > > if (!gimple_call_noreturn_p (assign))
> > > gimple_call_set_lhs (assign, *to_p);
> >
> > Ok, it seems to be too early then - move i
On Thu, Jan 09, 2014 at 01:30:53PM +0100, Richard Biener wrote:
> > gimplify_modify_expr has:
> >
> > if (!gimple_call_noreturn_p (assign))
> > gimple_call_set_lhs (assign, *to_p);
>
> Ok, it seems to be too early then - move it after the folding.
That wouldn't help all the other e
On Thu, 9 Jan 2014, Jakub Jelinek wrote:
> On Thu, Jan 09, 2014 at 12:31:47PM +0100, Richard Biener wrote:
> > On Thu, 9 Jan 2014, Jakub Jelinek wrote:
> >
> > > On Thu, Jan 09, 2014 at 12:15:00PM +0100, Richard Biener wrote:
> > > > > Well, then the __cxa_pure_virtual testcases ICE again, but th
On Thu, Jan 09, 2014 at 12:31:47PM +0100, Richard Biener wrote:
> On Thu, 9 Jan 2014, Jakub Jelinek wrote:
>
> > On Thu, Jan 09, 2014 at 12:15:00PM +0100, Richard Biener wrote:
> > > > Well, then the __cxa_pure_virtual testcases ICE again, but the
> > > > pr59622-5.C
> > > > testcase ICEs anyway,
On Thu, 9 Jan 2014, Jakub Jelinek wrote:
> On Thu, Jan 09, 2014 at 12:15:00PM +0100, Richard Biener wrote:
> > > Well, then the __cxa_pure_virtual testcases ICE again, but the pr59622-5.C
> > > testcase ICEs anyway, so here is a different patch (untested so far except
> > > for the tests). The is
On Thu, Jan 09, 2014 at 12:15:00PM +0100, Richard Biener wrote:
> > Well, then the __cxa_pure_virtual testcases ICE again, but the pr59622-5.C
> > testcase ICEs anyway, so here is a different patch (untested so far except
> > for the tests). The issue with the calls is that when fold_stmt is done
On Thu, 9 Jan 2014, Jakub Jelinek wrote:
> On Thu, Jan 09, 2014 at 09:46:11AM +0100, Richard Biener wrote:
> > > + /* If fndecl (like __builtin_unreachable or
> > > + __cxa_pure_virtual) takes no arguments, doesn't have
> > > + return value and is noreturn, if the call does
On Thu, Jan 09, 2014 at 09:46:11AM +0100, Richard Biener wrote:
> > + /* If fndecl (like __builtin_unreachable or
> > +__cxa_pure_virtual) takes no arguments, doesn't have
> > +return value and is noreturn, if the call doesn't have
> > +lhs or lhs isn't S
On Wed, 8 Jan 2014, Jakub Jelinek wrote:
> On Wed, Jan 08, 2014 at 12:19:02PM +0100, Richard Biener wrote:
> > On Wed, 8 Jan 2014, Jakub Jelinek wrote:
> >
> > > On Wed, Jan 08, 2014 at 12:15:40PM +0100, Richard Biener wrote:
> > > > > I start to think this is a too complex transform for stmt fol
On Wed, Jan 08, 2014 at 12:19:02PM +0100, Richard Biener wrote:
> On Wed, 8 Jan 2014, Jakub Jelinek wrote:
>
> > On Wed, Jan 08, 2014 at 12:15:40PM +0100, Richard Biener wrote:
> > > > I start to think this is a too complex transform for stmt folding ...
> > >
> > > Alternatively do update_call_f
On Wed, 8 Jan 2014, Jakub Jelinek wrote:
> On Wed, Jan 08, 2014 at 12:15:40PM +0100, Richard Biener wrote:
> > > I start to think this is a too complex transform for stmt folding ...
> >
> > Alternatively do update_call_from_tree (gsi, get_or_create_ssa_default_def
> > (cfun, create_tmp_var (TRE
On Wed, Jan 08, 2014 at 12:15:40PM +0100, Richard Biener wrote:
> > I start to think this is a too complex transform for stmt folding ...
>
> Alternatively do update_call_from_tree (gsi, get_or_create_ssa_default_def
> (cfun, create_tmp_var (TREE_TYPE (lhs.
The lhs might not be is_gimple_reg
On Wed, 8 Jan 2014, Richard Biener wrote:
> On Wed, 8 Jan 2014, Jakub Jelinek wrote:
>
> > On Wed, Jan 08, 2014 at 11:45:28AM +0100, Richard Biener wrote:
> > > I prefer to always do this, not do the fancy insertion-before. That
> > > would do repeated folding for
> > >
> > >fold_stmt (gsi)
On Wed, 8 Jan 2014, Jakub Jelinek wrote:
> On Wed, Jan 08, 2014 at 11:45:28AM +0100, Richard Biener wrote:
> > I prefer to always do this, not do the fancy insertion-before. That
> > would do repeated folding for
> >
> >fold_stmt (gsi);
> >fold_stmt (gsi);
> >fold_stmt (gsi);
> >
>
On Wed, Jan 08, 2014 at 11:45:28AM +0100, Richard Biener wrote:
> I prefer to always do this, not do the fancy insertion-before. That
> would do repeated folding for
>
>fold_stmt (gsi);
>fold_stmt (gsi);
>fold_stmt (gsi);
>
> where the last two should be a no-op.
I don't see how is
On Tue, 7 Jan 2014, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Jan 03, 2014 at 11:33:50AM +0100, Jakub Jelinek wrote:
> > On Fri, Jan 03, 2014 at 11:24:53AM +0100, Richard Biener wrote:
>
> Anyway, back to the original patch, so do you prefer something like
> this instead? I.e. handle only __builti
Hi!
On Fri, Jan 03, 2014 at 11:33:50AM +0100, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 11:24:53AM +0100, Richard Biener wrote:
Anyway, back to the original patch, so do you prefer something like
this instead? I.e. handle only __builtin_unreachable and
__cxa_pure_virtual specially, and not
On Fri, Jan 03, 2014 at 11:24:53AM +0100, Richard Biener wrote:
> works just fine for me but shows
>
> int (*) () f;
>
> int _4;
>
>
On Fri, 3 Jan 2014, Richard Biener wrote:
> On Fri, 3 Jan 2014, Jakub Jelinek wrote:
>
> > On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote:
> > > so if there is a decl then use its type signature, otherwise
> > > (indirect calls) use the caller signature (and hope it matches
> > >
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote:
> > so if there is a decl then use its type signature, otherwise
> > (indirect calls) use the caller signature (and hope it matches
> > the callee...). That it later falls back to looking at
On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote:
> so if there is a decl then use its type signature, otherwise
> (indirect calls) use the caller signature (and hope it matches
> the callee...). That it later falls back to looking at
> DECL_ARGUMENTS is odd (probably a FE issue wher
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 11:01:13AM +0100, Richard Biener wrote:
> > > Well, see PR59630. The question is if having to handle it everywhere
> > > is worth it.
> >
> > Well, this case happens because we go back to GENERIC which doesn't
> > have this featu
On Fri, Jan 03, 2014 at 11:01:13AM +0100, Richard Biener wrote:
> > Well, see PR59630. The question is if having to handle it everywhere
> > is worth it.
>
> Well, this case happens because we go back to GENERIC which doesn't
> have this feature. So "everywhere" is somewhat a broad stmt.
> It's
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 10:26:44AM +0100, Richard Biener wrote:
> > Jakub Jelinek wrote:
> > >On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
> > >> Meanwhile your patch is ok.
> > >
> > >As discussed in the PR, the patch wasn't sufficien
On Fri, Jan 03, 2014 at 10:26:44AM +0100, Richard Biener wrote:
> Jakub Jelinek wrote:
> >On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
> >> Meanwhile your patch is ok.
> >
> >As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual
> >can appear in the vtable and
Jakub Jelinek wrote:
>On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
>> Meanwhile your patch is ok.
>
>As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual
>can appear in the vtable and it has pretty much the same properties
>as __builtin_unreachable (void retur
On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
> Meanwhile your patch is ok.
As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual
can appear in the vtable and it has pretty much the same properties
as __builtin_unreachable (void return value, no arguments, noret
Jan Hubicka wrote:
>> >I think so, after all don't we set noreturn attribute automatically
>> >even if it is missing when IPA can prove the function never returns?
>> >If we fold_stmt after that, the above testcase even without explicit
>> >noreturn attribute would need cfg cleanup.
>> >
>> >Perha
> >I think so, after all don't we set noreturn attribute automatically
> >even if it is missing when IPA can prove the function never returns?
> >If we fold_stmt after that, the above testcase even without explicit
> >noreturn attribute would need cfg cleanup.
> >
> >Perhaps gimple_fold_call should
Jakub Jelinek wrote:
>On Tue, Dec 31, 2013 at 08:39:02AM +0100, Richard Biener wrote:
>> >That said, fold_stmt callers have to be prepared to handle say a
>normal
>> >call becoming noreturn call, consider say:
>> >
>> >struct A { virtual int foo (); };
>> >struct B : public A { int foo () __attrib
On Tue, Dec 31, 2013 at 08:39:02AM +0100, Richard Biener wrote:
> >That said, fold_stmt callers have to be prepared to handle say a normal
> >call becoming noreturn call, consider say:
> >
> >struct A { virtual int foo (); };
> >struct B : public A { int foo () __attribute__((noreturn)); };
> >int
Jakub Jelinek wrote:
>On Mon, Dec 30, 2013 at 10:14:16PM +0100, Jan Hubicka wrote:
>> this is C version
>> static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
>> main()
>> {
>> return p(1);
>> }
>
>Well, that testcase is invalid, as you are calling the function
>(builtin)
>through inc
> On Mon, Dec 30, 2013 at 10:14:16PM +0100, Jan Hubicka wrote:
> > this is C version
> > static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
> > main()
> > {
> > return p(1);
> > }
>
> Well, that testcase is invalid, as you are calling the function (builtin)
> through incompatible fun
On Mon, Dec 30, 2013 at 10:14:16PM +0100, Jan Hubicka wrote:
> this is C version
> static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
> main()
> {
> return p(1);
> }
Well, that testcase is invalid, as you are calling the function (builtin)
through incompatible function pointer, so al
Hi,
this is C version
static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
main()
{
return p(1);
}
Here we get in CCP:
Folding statement: return _4;
Not folded
Folding statement: _4 = p.0_2 (1);
Folded into: _4 = __builtin_unreachable (1);
Removing dead stmt p.0_2 = __builtin_unreacha
>
> Yes. Also affecting other statements isn't allowed.
>
> >One would need to also unlink vdefs and release the vdef SSA_NAME, and
> >not
> >sure if fold_stmt_inplace callers would be even prepared for the stmt
> >to
> >become noreturn, and no longer throwing, etc.
>
> That I think they have t
Jakub Jelinek wrote:
>On Mon, Dec 30, 2013 at 05:56:04PM +0100, Richard Biener wrote:
>> Jakub Jelinek wrote:
>> >Setting gimple_call_set_fndecl of a random method call to
>> >__bultin_unreachable can't work properly, the method call probably
>> >passes in arguments that __builtin_unreachable doe
On Mon, Dec 30, 2013 at 05:56:04PM +0100, Richard Biener wrote:
> Jakub Jelinek wrote:
> >Setting gimple_call_set_fndecl of a random method call to
> >__bultin_unreachable can't work properly, the method call probably
> >passes in arguments that __builtin_unreachable doesn't expect, and if
> >the
Jakub Jelinek wrote:
>Hi!
>
>Setting gimple_call_set_fndecl of a random method call to
>__bultin_unreachable can't work properly, the method call probably
>passes in arguments that __builtin_unreachable doesn't expect, and if
>the method call has LHS, we'll ICE, because __builtin_unreachable
>does
Hi!
Setting gimple_call_set_fndecl of a random method call to
__bultin_unreachable can't work properly, the method call probably
passes in arguments that __builtin_unreachable doesn't expect, and if
the method call has LHS, we'll ICE, because __builtin_unreachable doesn't
have a LHS. Fixed by not
44 matches
Mail list logo
