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. Richard. > Richard. > > > Martin > > > > > > > > jeff > > > > >
