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 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
>>> >> On 11 January 2
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:
> >> > On Fri, 12 Jan 2018, Prathamesh Kul
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 look OK ?
It simply checks in warn_function_malloc if function returns
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 wrote:
> >> >> On 11 January 2018 at 0
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 wrote:
>> >>> On 01/09/2018 05:57 AM, Pratham
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:
>
> As Jakub pointed out for
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"
- " and comparisons against 0."
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.
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 propagation would set f
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 requireme
>
> 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 oth
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()
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 malloc.
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 mar
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
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
void*f(){r
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 __builtin_malloc (0);
>>> }
>>>
>>> The malloc propagation would
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) returns NULL (?) and
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 se
n_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);
>> gca
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) ? __builtin_mal
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
> 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 consta
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
>
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 g(unsigned n)
>{
> return (n) ? __b
UMP_AND_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);
26 matches
Mail list logo
