On 10/3/19 6:47 AM, Andrea Corallo wrote: > > Jeff Law writes: > >> On 10/1/19 4:11 AM, Andrea Corallo wrote: >>> Martin Jambor writes: >>> >>>> Hi, >>>> >>>> On Mon, Sep 30 2019, Andrea Corallo wrote: >>>>> Hi all, >>>>> I'd like to submit this patch. >>>>> It release the ipa cp transformation summary after functions being >>>>> expanded. >>>>> This is to fix the compiler when used with libgccjit on subsequent >>>>> compilations (every new compilation should have a clean transformation >>>>> summary). >>>> if this is a general problem then I think we should instead add another >>>> hook to class ipa_opt_pass_d to free transformation summary, call it for >>>> all IPA passes at the appropriate time and implement it for IPA-CP. That >>>> way it will work for all IPA passes which might have a transformation >>>> summary. >>>> >>>> Martin >>>> >>>> >>>>> Bootstrap on arm64 and X86-64. >>>>> >>>>> Bests >>>>> Andrea >>>>> >>>>> gcc/ChangeLog >>>>> 2019-??-?? Andrea Corallo <andrea.cora...@arm.com> >>>>> >>>>> * cgraphunit.c (expand_all_functions): Release ipcp_transformation_sum >>>>> when finished. >>>>> * ipa-prop.c (ipcp_free_transformation_sum): New function. >>>>> * ipa-prop.h (ipcp_free_transformation_sum): Add declaration. >>> Hi, >>> actually looking around in order to implement the suggestions I realized >>> that already some code was put in place in toplev::finalize calling >>> then ipa_cp_c_finalize exactly for this purpose. >>> >>> I've updated the patch accordingly. >>> >>> Bootstraped on aarch64. >>> >>> Is it okay for trunk? >>> >>> Bests >>> Andrea >>> >>> gcc/ChangeLog >>> 2019-??-?? Andrea Corallo <andrea.cora...@arm.com> >>> >>> * ipa-cp.c (ipa_cp_c_finalize): Release ipcp_transformation_sum. >>> * ipa-prop.c (ipcp_free_transformation_sum): New function. >>> * ipa-prop.h (ipcp_free_transformation_sum): Add declaration. >> OK for the trunk. >> >> jeff > > Applied as r276507. > > The same patch applies cleanly onto gcc-9-branch, I think would be good to > back port it cause libgccjit is not very usable without. > Should we back port it? It's a bit out of the scope of what we usually backport, but I think this is a reasonable exception. So, yea, if you want, go ahead.
Thanks jeff
