Re: [RFC] ipa bitwise constant propagation

[Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>]

On 22 August 2016 at 19:24, Prathamesh Kulkarni
<prathamesh.kulkarni@linaro.org> wrote:
> On 22 August 2016 at 19:03, Martin Jambor <mjambor@suse.cz> wrote:
>> Hi,
>>
>> On Tue, Aug 16, 2016 at 06:34:48PM +0530, Prathamesh Kulkarni wrote:
>>> Thanks, I updated the patch to address these issues (attached).
>>> However the patch caused ICE during testing
>>> objc.dg/torture/forward-1.m (and few others but with same ICE):
>>>
>>> Command line options:
>>> /home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/gcc/xgcc
>>> -B/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/gcc/
>>> /home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/gcc/gcc/testsuite/objc.dg/torture/forward-1.m
>>> -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto
>>> -fuse-linker-plugin -fno-fat-lto-objects -fgnu-runtime
>>> -I/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/gcc/gcc/testsuite/../../libobjc
>>> -B/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/x86_64-pc-linux-gnu/./libobjc/.libs
>>> -L/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/x86_64-pc-linux-gnu/./libobjc/.libs
>>> -lobjc -lm -o ./forward-1.exe
>>>
>>> Backtrace:
>>> 0x8c0ed2 ipa_get_param_decl_index_1
>>> ../../gcc/gcc/ipa-prop.c:106
>>> 0x8b7dbb will_be_nonconstant_predicate
>>> ../../gcc/gcc/ipa-inline-analysis.c:2110
>>> 0x8b7dbb estimate_function_body_sizes
>>> ../../gcc/gcc/ipa-inline-analysis.c:2739
>>> 0x8bae26 compute_inline_parameters(cgraph_node*, bool)
>>> ../../gcc/gcc/ipa-inline-analysis.c:3030
>>> 0x8bb309 inline_analyze_function(cgraph_node*)
>>> ../../gcc/gcc/ipa-inline-analysis.c:4157
>>> 0x11dc402 ipa_icf::sem_function::merge(ipa_icf::sem_item*)
>>> ../../gcc/gcc/ipa-icf.c:1345
>>> 0x11d6334 ipa_icf::sem_item_optimizer::merge_classes(unsigned int)
>>> ../../gcc/gcc/ipa-icf.c:3461
>>> 0x11e12c6 ipa_icf::sem_item_optimizer::execute()
>>> ../../gcc/gcc/ipa-icf.c:2636
>>> 0x11e34d6 ipa_icf_driver
>>> ../../gcc/gcc/ipa-icf.c:3538
>>> 0x11e34d6 ipa_icf::pass_ipa_icf::execute(function*)
>>> ../../gcc/gcc/ipa-icf.c:3585
>>>
>>> This appears due to following assert in ipa_get_param_decl_index_1():
>>> gcc_checking_assert (!flag_wpa);
>>> which was added by Martin's patch introducing ipa_get_type().
>>> Removing the assert works, however I am not sure if that's the correct thing.
>>> I would be grateful for suggestions on how to handle this case.
>>>
>>
>> I wrote that the patch was not really tested, I did not think about
>> ICF loading bodies and re-running body-analyses at WPO time.
>> Nevertheless, after some consideration, I think that just removing the
>> assert is fine.  After all, the caller must have passed a PARM_DECL if
>> it is doing anything sensible at all and that means we have access to
>> the function body.
> Thanks for the pointers. I will validate the patch after removing assert,
> and get back.
Hi,
The attached version passes bootstrap+test on
x86_64-unknown-linux-gnu, ppc64le-linux-gnu,
and with c,c++,fortran on armv8l-linux-gnueabihf.
Cross-tested on arm*-*-* and aarch64*-*-*.
Verified the patch survives lto-bootstrap on x86_64-unknown-linux-gnu.
Ok to commit ?

Thanks,
Prathamesh
>
> Thanks,
> Prathamesh
>>
>> Thanks,
>>
>> Martin

Attachment: bits-prop-7.txt
Description: Text document