On 11/4/19 6:36 AM, Richard Biener wrote: > On Mon, Nov 4, 2019 at 2:35 PM Richard Biener > <richard.guent...@gmail.com> wrote: >> >> On Mon, Nov 4, 2019 at 10:09 AM Martin Liška <mli...@suse.cz> wrote: >>> >>> On 11/1/19 10:51 PM, Jeff Law wrote: >>>> On 10/31/19 10:01 AM, Martin Liška wrote: >>>>> Hi. >>>>> >>>>> operand_equal_p can properly handle situation where we have a CONSTRUCTOR >>>>> where indices are NULL: >>>>> >>>>> if (!operand_equal_p (c0->value, c1->value, flags) >>>>> /* In GIMPLE the indexes can be either NULL or matching i. >>>>> Double check this so we won't get false >>>>> positives for GENERIC. */ >>>>> || (c0->index >>>>> && (TREE_CODE (c0->index) != INTEGER_CST >>>>> || compare_tree_int (c0->index, i))) >>>>> || (c1->index >>>>> && (TREE_CODE (c1->index) != INTEGER_CST >>>>> || compare_tree_int (c1->index, i)))) >>>>> return false; >>>>> >>>>> but the corresponding hash function always hashes field (which >>>>> can be NULL_TREE or equal to ctor index). >>>>> >>>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >>>>> >>>>> Ready to be installed? >>>>> Thanks, >>>>> Martin >>>>> >>>>> gcc/ChangeLog: >>>>> >>>>> 2019-10-31 Martin Liska <mli...@suse.cz> >>>>> >>>>> PR ipa/92304 >>>>> * fold-const.c (operand_compare::hash_operand): Fix field >>>>> hashing of CONSTRUCTOR. >>>> OK. One question though, do these routines need to handle >>>> CONSTRUCTOR_NO_CLEARING? >>> >>> Good point, but I bet it's just a flag used in GENERIC, right? >> >> Yes. It matters for gimplification only. I don't think we can >> optimistically make use of it in operand_equal_p. > > OTOH for GENERIC and sth like ICF the flags have to match. Precisely my concern. I'm not immediately aware of any case where it matters, but it'd be nice to future proof this if we can.
jeff
