[RFC] ipa bitwise constant propagation

Prathamesh Kulkarni prathamesh.kulkarni@linaro.org
Fri Aug 12 09:54:00 GMT 2016


On 11 August 2016 at 18:25, Jan Hubicka <hubicka@ucw.cz> wrote:
>> @@ -266,6 +267,38 @@ private:
>>    bool meet_with_1 (unsigned new_align, unsigned new_misalign);
>>  };
>>
>> +/* Lattice of known bits, only capable of holding one value.
>> +   Similar to ccp_lattice_t, mask represents which bits of value are constant.
>> +   If a bit in mask is set to 0, then the corresponding bit in
>> +   value is known to be constant.  */
>> +
>> +class ipcp_bits_lattice
>> +{
>> +public:
>> +  bool bottom_p () { return m_lattice_val == IPA_BITS_VARYING; }
>> +  bool top_p () { return m_lattice_val == IPA_BITS_UNDEFINED; }
>> +  bool constant_p () { return m_lattice_val == IPA_BITS_CONSTANT; }
>> +  bool set_to_bottom ();
>> +  bool set_to_constant (widest_int, widest_int);
>> +
>> +  widest_int get_value () { return m_value; }
>> +  widest_int get_mask () { return m_mask; }
>> +
>> +  bool meet_with (ipcp_bits_lattice& other, unsigned, signop,
>> +               enum tree_code, tree);
>> +
>> +  bool meet_with (widest_int, widest_int, unsigned);
>> +
>> +  void print (FILE *);
>> +
>> +private:
>> +  enum { IPA_BITS_UNDEFINED, IPA_BITS_CONSTANT, IPA_BITS_VARYING } m_lattice_val;
>> +  widest_int m_value, m_mask;
>
> Please add comment for these, like one in tree-ssa-ccp and mention they are the same
> values.
>
>> +
>> +  /* For K&R C programs, ipa_get_type() could return NULL_TREE.
>> +     Avoid the transform for these cases.  */
>> +  if (!parm_type)
>> +    return dest_lattice->set_to_bottom ();
>
> Please add TDF_DETAILS dump for this so we notice if we drop useful info for no
> good reasons.  It also happens for variadic functions but hopefully not much more.
>
> The patch is OK with those changes.
Hi,
The patch broke bootstrap due to segfault while compiling libsupc++/eh_alloc.cc
in ipa_get_type() because callee_info->descriptors had 0 length in
propagate_bits_accross_call.

After debugging a bit, I realized it was incorrect to use cs->callee and
using cs->callee->function_symbol() fixed it:
(that seemed to match with value of 'callee' variable in
propagate_constants_accross_call).

-  struct ipa_node_params *callee_info = IPA_NODE_REF (cs->callee);
+  enum availability availability;
+  cgraph_node *callee = cs->callee->function_symbol (&availability);
+  struct ipa_node_params *callee_info = IPA_NODE_REF (callee);
   tree parm_type = ipa_get_type (callee_info, idx);

Similarly I wonder if cs->caller->function_symbol() should be used
instead of cs->caller in following place while obtaining lattices of
source param ?

  if (jfunc->type == IPA_JF_PASS_THROUGH)
    {
      struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);


The patch segfaults with -flto for gcc.c-torture/execute/920302-1.c in
ipcp_propagate_stage ()
while populating info->descriptors[k].decl_or_type because t becomes
NULL and we dereference
it with TREE_VALUE (t)
The test-case has K&R style param declaration.
The following change seems to fix it for me:

@@ -3235,7 +3235,7 @@ ipcp_propagate_stage (struct ipa_topo_info *topo)
     if (in_lto_p)
       {
        tree t = TYPE_ARG_TYPES (TREE_TYPE (node->decl));
-       for (int k = 0; k < ipa_get_param_count (info); k++)
+       for (int k = 0; k < ipa_get_param_count (info) && t; k++)
          {
            gcc_assert (t != void_list_node);
            info->descriptors[k].decl_or_type = TREE_VALUE (t);

Is that change OK ?

PS: I am on vacation for next week, will get back to working on the
patch after returning.

Thanks,
Prathamesh
>
> thanks,
> Honza



More information about the Gcc-patches mailing list