Hi,
On Tue, Apr 08 2025, Jan Hubicka wrote:
>> After the propagation of constants and value ranges, it turns out
>> that the propagation of known bits also needs to be made aware of any
>> intermediate types in which any arithmetic operations are made and
>> must limit its precision there. This implements just that, using the
>> newly collected and streamed types of the operations involved.
>>
>> Bootstrapped and tested and LTO bootstrapped on x86_64-linux. OK for
>> master?
>>
>> Thanks,
>>
>> Martin
>>
>>
>> gcc/ChangeLog:
>>
>> 2025-03-20 Martin Jambor <mjam...@suse.cz>
>>
>> PR ipa/119318
>> * ipa-cp.cc (ipcp_bits_lattice::meet_with_1): Set all mask bits
>> not covered by precision to one.
>> (ipcp_bits_lattice::meet_with): Likewise.
>> (propagate_bits_across_jump_function): Use the first operand type
>> rather than the final parameter one to perform meet with other
>> lattices. Check the operation conforms with
>> expr_type_first_operand_type_p.
>> * tree.cc (expr_type_first_operand_type_p): Add POINTER_PLUS_EXPR.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2025-03-18 Martin Jambor <mjam...@suse.cz>
>>
>> PR ipa/119318
>> * gcc.dg/ipa/pr119318.c: New test.
>> + if (!op_type)
>> + {
>> + op_type = ipa_get_type (caller_info, src_idx);
>> + if (!op_type)
>> + {
>> + if (dump_file && (dump_flags & TDF_DETAILS))
>> + fprintf (dump_file, "Setting dest_lattice to bottom, "
>> + "because the operation involved in computing "
>> + "param %i of %s is in an unknown type.\n",
>> + idx, cs->callee->dump_name ());
>> + return dest_lattice->set_to_bottom ();
>> + }
>> + }
>
> When this can happen?
> I can see that get_ipa_type returns NULL when there are no descriptor or
> respective descriptor has NULL type, but I wonder in what cases this
> happens in practice...
That is a fair point, if we have jump functions for calls in a function,
we will nowadays always have types of its formal parameters. I'll be
happy to replace the condition with an assert.
Martin
