This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix hash_operand for fields of a CONSTRUCTOR.


On 11/5/19 1:35 AM, Martin Liška wrote:
> On 11/4/19 4:24 PM, Jeff Law wrote:
>> On 11/4/19 6:36 AM, Richard Biener wrote:
>>> On Mon, Nov 4, 2019 at 2:35 PM Richard Biener
>>> <richard.guenther@gmail.com> wrote:
>>>>
>>>> On Mon, Nov 4, 2019 at 10:09 AM Martin Liška <mliska@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  <mliska@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
>>
> 
> Sure, I've got the following tested patch.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> 0001-Add-CONSTRUCTOR_NO_CLEARING-to-operand_equal_p.patch
> 
> From 2302c15cb2568bc71b4b7bc3abbfd66aafc7c06c Mon Sep 17 00:00:00 2001
> From: Martin Liska <mliska@suse.cz>
> Date: Mon, 4 Nov 2019 15:39:40 +0100
> Subject: [PATCH] Add CONSTRUCTOR_NO_CLEARING to operand_equal_p.
> 
> gcc/ChangeLog:
> 
> 2019-11-04  Martin Liska  <mliska@suse.cz>
> 
> 	* fold-const.c (operand_compare::operand_equal_p): Add comparison
> 	of CONSTRUCTOR_NO_CLEARING.
> 	(operand_compare::hash_operand): Likewise.
OK
jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]