Re: PR83648

2018-05-17 Thread H.J. Lu
On Mon, May 14, 2018 at 11:11 PM, Prathamesh Kulkarni wrote: > On 12 January 2018 at 18:26, Richard Biener wrote: >> On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote: >> >>> On 12 January 2018 at 05:02, Jeff Law wrote: >>> > On

Re: PR83648

2018-05-17 Thread Richard Biener
On Thu, May 17, 2018 at 1:25 PM Prathamesh Kulkarni < prathamesh.kulka...@linaro.org> wrote: > On 15 May 2018 at 12:20, Richard Biener wrote: > > On Tue, 15 May 2018, Prathamesh Kulkarni wrote: > > > >> On 12 January 2018 at 18:26, Richard Biener wrote: >

Re: PR83648

2018-05-17 Thread Prathamesh Kulkarni
> >> 2] Return value is phi result, and all args of phi are 0. > > In which case constant propagation should have eliminated the PHI. > >> 3] Any other cases ? > > Can't think of any. Please create testcases for all cases you > fend off. Hi, Does the attached patch

Re: PR83648

2018-05-15 Thread Richard Biener
On Tue, 15 May 2018, Prathamesh Kulkarni wrote: > On 12 January 2018 at 18:26, Richard Biener wrote: > > On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote: > > > >> On 12 January 2018 at 05:02, Jeff Law wrote: > >> > On 01/10/2018 10:04 PM, Prathamesh Kulkarni

Re: PR83648

2018-05-15 Thread Prathamesh Kulkarni
On 12 January 2018 at 18:26, Richard Biener wrote: > On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote: > >> On 12 January 2018 at 05:02, Jeff Law wrote: >> > On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote: >> >> On 11 January 2018 at 04:50, Jeff Law

Re: PR83648

2018-01-12 Thread Richard Biener
On Fri, 12 Jan 2018, Prathamesh Kulkarni wrote: > On 12 January 2018 at 05:02, Jeff Law wrote: > > On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote: > >> On 11 January 2018 at 04:50, Jeff Law wrote: > >>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote: >

Re: PR83648

2018-01-11 Thread Prathamesh Kulkarni
if (TREE_CODE (arg) != SSA_NAME) - DUMP_AND_RETURN("phi arg is not SSA_NAME.") - if (!(arg == null_pointer_node || check_retval_uses (arg, phi))) - DUMP_AND_RETURN("phi arg has uses outside phi" - " an

Re: PR83648

2018-01-11 Thread Jeff Law
On 01/11/2018 01:27 AM, Richard Biener wrote: > On Thu, 11 Jan 2018, Marc Glisse wrote: > >> On Tue, 9 Jan 2018, Prathamesh Kulkarni wrote: >> >>> As Jakub pointed out for the case: >>> void *f() >>> { >>> return __builtin_malloc (0); >>> } >>> >>> The malloc propagation would set f() to malloc.

Re: PR83648

2018-01-11 Thread Jeff Law
On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote: > On 11 January 2018 at 04:50, Jeff Law wrote: >> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote: >>> >>> As Jakub pointed out for the case: >>> void *f() >>> { >>> return __builtin_malloc (0); >>> } >>> >>> The malloc

Re: PR83648

2018-01-11 Thread Martin Sebor
On 01/11/2018 01:32 PM, Jan Hubicka wrote: As long as the marked definition still satisfies the assumptions GCC makes about the function it won't be harmful. I don't know all the nuances of pointer aliasing in GCC that might rely on it but assuming they faithfully reflect the standard

Re: PR83648

2018-01-11 Thread Jan Hubicka
> > As long as the marked definition still satisfies the assumptions > GCC makes about the function it won't be harmful. I don't know > all the nuances of pointer aliasing in GCC that might rely on it > but assuming they faithfully reflect the standard requirements > it will be safe. > > The

Re: PR83648

2018-01-11 Thread Martin Sebor
On 01/11/2018 12:22 PM, Jeff Law wrote: On 01/11/2018 11:56 AM, Martin Sebor wrote: On 01/10/2018 04:20 PM, Jeff Law wrote: On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote: As Jakub pointed out for the case: void *f() { return __builtin_malloc (0); } The malloc propagation would set f()

Re: PR83648

2018-01-11 Thread Jeff Law
On 01/11/2018 11:56 AM, Martin Sebor wrote: > On 01/10/2018 04:20 PM, Jeff Law wrote: >> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote: >>> >>> As Jakub pointed out for the case: >>> void *f() >>> { >>>   return __builtin_malloc (0); >>> } >>> >>> The malloc propagation would set f() to

Re: PR83648

2018-01-11 Thread Martin Sebor
On 01/10/2018 04:20 PM, Jeff Law wrote: On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote: As Jakub pointed out for the case: void *f() { return __builtin_malloc (0); } The malloc propagation would set f() to malloc. However AFAIU, malloc(0) returns NULL (?) and the function shouldn't be

Re: PR83648

2018-01-11 Thread Richard Biener
On Thu, 11 Jan 2018, Marc Glisse wrote: > On Tue, 9 Jan 2018, Prathamesh Kulkarni wrote: > > > As Jakub pointed out for the case: > > void *f() > > { > > return __builtin_malloc (0); > > } > > > > The malloc propagation would set f() to malloc. > > However AFAIU, malloc(0) returns NULL (?) and

Re: PR83648

2018-01-10 Thread Marc Glisse
On Tue, 9 Jan 2018, Prathamesh Kulkarni wrote: As Jakub pointed out for the case: void *f() { return __builtin_malloc (0); } The malloc propagation would set f() to malloc. However AFAIU, malloc(0) returns NULL (?) and the function shouldn't be marked as malloc ? Why not? Even for

Re: PR83648

2018-01-10 Thread Prathamesh Kulkarni
On 11 January 2018 at 10:34, Prathamesh Kulkarni wrote: > On 11 January 2018 at 04:50, Jeff Law wrote: >> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote: >>> >>> As Jakub pointed out for the case: >>> void *f() >>> { >>> return

Re: PR83648

2018-01-10 Thread Prathamesh Kulkarni
On 11 January 2018 at 04:50, Jeff Law wrote: > On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote: >> >> As Jakub pointed out for the case: >> void *f() >> { >> return __builtin_malloc (0); >> } >> >> The malloc propagation would set f() to malloc. >> However AFAIU, malloc(0)

Re: PR83648

2018-01-10 Thread Jeff Law
On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote: > > As Jakub pointed out for the case: > void *f() > { > return __builtin_malloc (0); > } > > The malloc propagation would set f() to malloc. > However AFAIU, malloc(0) returns NULL (?) and the function shouldn't > be marked as malloc ? This

Re: PR83648

2018-01-09 Thread Prathamesh Kulkarni
_builtin_malloc (0); } The malloc propagation would set f() to malloc. However AFAIU, malloc(0) returns NULL (?) and the function shouldn't be marked as malloc ? Thanks, Prathamesh > > Honza >> >> gimple *arg_def = SSA_NAME_DEF_STMT (arg); >> gcall *ca

Re: PR83648

2018-01-03 Thread Jeff Law
On 01/02/2018 11:03 PM, Prathamesh Kulkarni wrote: > Hi, > malloc_candidate_p() in ipa-pure-const misses detecting that a > function is malloc-like if the return value is result of PHI and one > of the arguments of PHI is 0. > For example: > > void g(unsigned n) > { > return (n) ?

Re: PR83648

2018-01-03 Thread Jan Hubicka
also handle a case where parameter of phi is another phi? Honza > > gimple *arg_def = SSA_NAME_DEF_STMT (arg); > gcall *call_stmt = dyn_cast (arg_def); > diff --git a/gcc/testsuite/gcc.dg/ipa/pr83648.c > b/gcc/testsuite/gcc.dg/ipa/pr83648.c > new file mod

Re: PR83648

2018-01-03 Thread Jan Hubicka
> On Wed, Jan 03, 2018 at 10:05:30AM +0100, Richard Biener wrote: > > >One concern I have is that with the patch, malloc_candidate_p will > > >return true if all the args to PHI are NULL: > > >retval = PHI<0, 0> > > >return retval > > > > > >However I expect that PHI with all 0 args would be

Re: PR83648

2018-01-03 Thread Jakub Jelinek
On Wed, Jan 03, 2018 at 10:05:30AM +0100, Richard Biener wrote: > >One concern I have is that with the patch, malloc_candidate_p will > >return true if all the args to PHI are NULL: > >retval = PHI<0, 0> > >return retval > > > >However I expect that PHI with all 0 args would be constant folded to

Re: PR83648

2018-01-03 Thread Richard Biener
On January 3, 2018 7:03:26 AM GMT+01:00, Prathamesh Kulkarni wrote: >Hi, >malloc_candidate_p() in ipa-pure-const misses detecting that a >function is malloc-like if the return value is result of PHI and one >of the arguments of PHI is 0. >For example: > >void

PR83648

2018-01-02 Thread Prathamesh Kulkarni
ND_RETURN ("phi arg is not SSA_NAME."); + if (!check_retval_uses (arg, phi)) + DUMP_AND_RETURN ("phi arg has uses outside phi" + " and comparisons against 0.") gimple *arg_def = SSA_NAME_DEF_STMT (arg);