On Fri, 27 Oct 2017, Jan Hubicka wrote:
> > On 25 October 2017 at 20:44, Jan Hubicka wrote:
> > >> On 24 October 2017 at 16:26, Jan Hubicka wrote:
> > >> >> 2017-10-13 Prathamesh Kulkarni
> > >> >>
> > >> >> * cgraph.h (set_malloc_flag): Declare.
> > >> >> * cgraph.c (set_malloc_f
> On 25 October 2017 at 20:44, Jan Hubicka wrote:
> >> On 24 October 2017 at 16:26, Jan Hubicka wrote:
> >> >> 2017-10-13 Prathamesh Kulkarni
> >> >>
> >> >> * cgraph.h (set_malloc_flag): Declare.
> >> >> * cgraph.c (set_malloc_flag_1): New function.
> >> >> (set_malloc_flag)
Prathamesh
> > OK, thanks!
> Thanks, committed as r254140 after following validation:
> 1] Bootstrap+test with --enable-languages=all,ada,go on
> x86_64-unknown-linux-gnu and ppc64le-linux-gnu.
> 2] LTO bootstrap+test on x86_64-unknown-linux-gnu and ppc64le-linux-gnu
> 3] Cross tested on arm*-*-* a
On 25 October 2017 at 20:44, Jan Hubicka wrote:
>> On 24 October 2017 at 16:26, Jan Hubicka wrote:
>> >> 2017-10-13 Prathamesh Kulkarni
>> >>
>> >> * cgraph.h (set_malloc_flag): Declare.
>> >> * cgraph.c (set_malloc_flag_1): New function.
>> >> (set_malloc_flag): Likewise.
>>
> On 24 October 2017 at 16:26, Jan Hubicka wrote:
> >> 2017-10-13 Prathamesh Kulkarni
> >>
> >> * cgraph.h (set_malloc_flag): Declare.
> >> * cgraph.c (set_malloc_flag_1): New function.
> >> (set_malloc_flag): Likewise.
> >> * ipa-fnsummary.h (ipa_call_summary): Add new
On 24 October 2017 at 16:26, Jan Hubicka wrote:
>> 2017-10-13 Prathamesh Kulkarni
>>
>> * cgraph.h (set_malloc_flag): Declare.
>> * cgraph.c (set_malloc_flag_1): New function.
>> (set_malloc_flag): Likewise.
>> * ipa-fnsummary.h (ipa_call_summary): Add new field is_retur
> 2017-10-13 Prathamesh Kulkarni
>
> * cgraph.h (set_malloc_flag): Declare.
> * cgraph.c (set_malloc_flag_1): New function.
> (set_malloc_flag): Likewise.
> * ipa-fnsummary.h (ipa_call_summary): Add new field is_return_callee.
> * ipa-fnsummary.c (ipa_call_summary:
On 14 October 2017 at 03:20, Prathamesh Kulkarni
wrote:
> On 7 October 2017 at 12:35, Prathamesh Kulkarni
> wrote:
>> On 7 October 2017 at 11:23, Jan Hubicka wrote:
On 6 October 2017 at 06:04, Jan Hubicka wrote:
>> Hi Honza,
>> Thanks for the detailed suggestions, I have updated
On 7 October 2017 at 12:35, Prathamesh Kulkarni
wrote:
> On 7 October 2017 at 11:23, Jan Hubicka wrote:
>>> On 6 October 2017 at 06:04, Jan Hubicka wrote:
>>> >> Hi Honza,
>>> >> Thanks for the detailed suggestions, I have updated the patch
>>> >> accordingly.
>>> >> I have following questions
On 7 October 2017 at 11:23, Jan Hubicka wrote:
>> On 6 October 2017 at 06:04, Jan Hubicka wrote:
>> >> Hi Honza,
>> >> Thanks for the detailed suggestions, I have updated the patch accordingly.
>> >> I have following questions on call_summary:
>> >> 1] I added field bool is_return_callee in ipa_c
> On 6 October 2017 at 06:04, Jan Hubicka wrote:
> >> Hi Honza,
> >> Thanks for the detailed suggestions, I have updated the patch accordingly.
> >> I have following questions on call_summary:
> >> 1] I added field bool is_return_callee in ipa_call_summary to track
> >> whether the caller possibly
On 6 October 2017 at 06:04, Jan Hubicka wrote:
>> Hi Honza,
>> Thanks for the detailed suggestions, I have updated the patch accordingly.
>> I have following questions on call_summary:
>> 1] I added field bool is_return_callee in ipa_call_summary to track
>> whether the caller possibly returns val
> Hi Honza,
> Thanks for the detailed suggestions, I have updated the patch accordingly.
> I have following questions on call_summary:
> 1] I added field bool is_return_callee in ipa_call_summary to track
> whether the caller possibly returns value returned by callee, which
> gets rid of return_cal
On 29 September 2017 at 12:28, Jan Hubicka wrote:
>> > I wonder what happens here when, say, ipa-icf redirect the call to
>> > eqivaelnt
>> > function and removes the callee? Perhaps we realy want to have set of call
>> > sites rahter than nodes stored from analysis to execution. Call sites have
> > I wonder what happens here when, say, ipa-icf redirect the call to eqivaelnt
> > function and removes the callee? Perhaps we realy want to have set of call
> > sites rahter than nodes stored from analysis to execution. Call sites have
> > unique stmts and uids, so it will be possible to map th
On 25 September 2017 at 17:24, Jan Hubicka wrote:
>> Hi Honza,
>> Could you please have a look at this patch ?
>> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg02063.html
>
> I can and I should have done long time ago. I really apologize for slow
> response
> and I will try to be more timely from
> Hi Honza,
> Could you please have a look at this patch ?
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg02063.html
I can and I should have done long time ago. I really apologize for slow response
and I will try to be more timely from now on. The reason was that I had some
patches that I was thi
On 15 September 2017 at 17:49, Prathamesh Kulkarni
wrote:
> On 1 September 2017 at 08:09, Prathamesh Kulkarni
> wrote:
>> On 17 August 2017 at 18:02, Prathamesh Kulkarni
>> wrote:
>>> On 8 August 2017 at 09:50, Prathamesh Kulkarni
>>> wrote:
On 31 July 2017 at 23:53, Prathamesh Kulkarni
>>
On 1 September 2017 at 08:09, Prathamesh Kulkarni
wrote:
> On 17 August 2017 at 18:02, Prathamesh Kulkarni
> wrote:
>> On 8 August 2017 at 09:50, Prathamesh Kulkarni
>> wrote:
>>> On 31 July 2017 at 23:53, Prathamesh Kulkarni
>>> wrote:
On 23 May 2017 at 19:10, Prathamesh Kulkarni
wr
On 17 August 2017 at 18:02, Prathamesh Kulkarni
wrote:
> On 8 August 2017 at 09:50, Prathamesh Kulkarni
> wrote:
>> On 31 July 2017 at 23:53, Prathamesh Kulkarni
>> wrote:
>>> On 23 May 2017 at 19:10, Prathamesh Kulkarni
>>> wrote:
On 19 May 2017 at 19:02, Jan Hubicka wrote:
>>
>>
On 8 August 2017 at 09:50, Prathamesh Kulkarni
wrote:
> On 31 July 2017 at 23:53, Prathamesh Kulkarni
> wrote:
>> On 23 May 2017 at 19:10, Prathamesh Kulkarni
>> wrote:
>>> On 19 May 2017 at 19:02, Jan Hubicka wrote:
>
> * LTO and memory management
> This is a general question about
On 31 July 2017 at 23:53, Prathamesh Kulkarni
wrote:
> On 23 May 2017 at 19:10, Prathamesh Kulkarni
> wrote:
>> On 19 May 2017 at 19:02, Jan Hubicka wrote:
* LTO and memory management
This is a general question about LTO and memory management.
IIUC the following sequence take
On 23 May 2017 at 19:10, Prathamesh Kulkarni
wrote:
> On 19 May 2017 at 19:02, Jan Hubicka wrote:
>>>
>>> * LTO and memory management
>>> This is a general question about LTO and memory management.
>>> IIUC the following sequence takes place during normal LTO:
>>> LGEN: generate_summary, write_su
On 19 May 2017 at 19:02, Jan Hubicka wrote:
>>
>> * LTO and memory management
>> This is a general question about LTO and memory management.
>> IIUC the following sequence takes place during normal LTO:
>> LGEN: generate_summary, write_summary
>> WPA: read_summary, execute ipa passes, write_opt_su
>
> * LTO and memory management
> This is a general question about LTO and memory management.
> IIUC the following sequence takes place during normal LTO:
> LGEN: generate_summary, write_summary
> WPA: read_summary, execute ipa passes, write_opt_summary
>
> So I assumed it was OK in LGEN to alloc
> > struct D: B {
> > char buf[32];
> > virtual void* f (unsigned n) {
> > if (n < 32)
> > return n <= 32 ? buf : B::f (n);
> > }
> >
> > Breaking foo's attribute malloc constraint.
> >
> > In other words, I think virtual functions need to be excluded
> > from the list (
On Wed, 17 May 2017, Martin Sebor wrote:
> > The patch passes bootstrap+test on x86_64 and found a few functions in
> > the source tree (attached func_names.txt) that could be annotated with
> > malloc (I gave a brief look at some of the functions and didn't appear
> > to be false positives but I
The patch passes bootstrap+test on x86_64 and found a few functions in
the source tree (attached func_names.txt) that could be annotated with
malloc (I gave a brief look at some of the functions and didn't appear
to be false positives but I will recheck thoroughly)
virtual char* libcp1::compiler
On Mon, 15 May 2017, Prathamesh Kulkarni wrote:
> Hi,
> I have attached a bare-bones prototype patch that propagates malloc attribute
> in
> ipa-pure-const. As far as I understand, from the doc a function could
> be annotated
> with malloc attribute if it returns a pointer to a newly allocated
>
On 05/15/2017 04:39 AM, Prathamesh Kulkarni wrote:
Hi,
I have attached a bare-bones prototype patch that propagates malloc attribute in
ipa-pure-const. As far as I understand, from the doc a function could
be annotated
with malloc attribute if it returns a pointer to a newly allocated
memory bloc
30 matches
Mail list logo
