From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128195 invoked by alias); 20 Aug 2019 12:54:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 128171 invoked by uid 89); 20 Aug 2019 12:54:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=born X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Aug 2019 12:54:52 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 530352825E3; Tue, 20 Aug 2019 14:54:49 +0200 (CEST) Date: Tue, 20 Aug 2019 14:42:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Martin Liska , GCC Patches Subject: Re: [PATCH 3/9] operand_equal_p: add support for OBJ_TYPE_REF. Message-ID: <20190820125449.uxytg4dyr3rh3f5c@kam.mff.cuni.cz> References: <20190815145711.GA21034@atrey.karlin.mff.cuni.cz> <20190816120727.wttrwdhp4dphkksx@kam.mff.cuni.cz> <20190819143404.n236wnzxkjghpewp@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2019-08/txt/msg01418.txt.bz2 > I see. I guess dropping them if !virtual_method_call_p (at what point > do we know?) would be a good thing. As well as encoding > "types_same_for_odr" and obj_type_ref_class in a more direct manner. > I guess in reality OBJ_TYPE_REF should be all info on the > gimple_call rather than in a GENERIC tree in the call fn slot or > a separate stmt ... > > Anyhow, the original patch is OK if you compare > OBJ_TYPE_REF_TOKEN/OBJECT irrespective of virtual_method_call_p > and order the types_same_for_odr last since that's most expensive. > I also wonder if virtual_method_call_p needs to return a virtual_mehtod_call_p is constant on the expression thorough compilation. I.e. if OBJ_TYPE_REF is born in C++ FE it will return true if it is Obj-C FE it will return false and we will completely ignore that OBJ_TYPE_REF in the middle-end (and thus we probably want to drop it - I was just never brave enough to dig into obj-C gimplification to figure out where it should be done and I also do not know how OBJ-C uses OBJ_TYPE_REFs internally if at all) Honza > "maybe" and we have to say not equal in that case rather than just > not comparing obj_type_ref_class ... (operand_equal_p might be called > from FEs during parsing) > > Richard. > > Thanks, > Richard. > > > Honza