From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id A1D80395B044; Tue, 22 Jun 2021 21:58:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A1D80395B044 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 587CC1FD45; Tue, 22 Jun 2021 21:58:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1624399113; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lFYOU6IHre5ENNymWPAepR3uG+32xwoa4BGd/oXrYVI=; b=ZHRIKPzbga9xJ1QvOSZu5QoI2zs2eMbIsdGe5gmBq7t6WtgfWTy2AeKNhf3SxbDTdlvpJ8 0t8gQLOLV9ef+BmT/7Z+iAg/1chJObZ5UC0RHOC0/PJpZ87Wxu1aw6rDJJgMrpgtskLPEc kWaesUx2AVcVBM+FUUMImpmtSLsg0rQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1624399113; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lFYOU6IHre5ENNymWPAepR3uG+32xwoa4BGd/oXrYVI=; b=i1CYV26gYCxiBT6zZ29dlCfr9W1uL5VKncBF9r45UOPUw28h9gDAGyN0GTt4usvBjUGoA0 HFlL0fJY5FUZrnCQ== Received: from suse.cz (unknown [10.100.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 3A6E2A3B9A; Tue, 22 Jun 2021 21:58:33 +0000 (UTC) From: Martin Jambor To: Erick Ochoa , gcc@gcc.gnu.org Cc: Jan Hubicka Subject: Re: Semantics of OBJ_TYPE_REF In-Reply-To: References: User-Agent: Notmuch/0.32 (https://notmuchmail.org) Emacs/27.2 (x86_64-suse-linux-gnu) Date: Tue, 22 Jun 2021 23:58:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 21:58:36 -0000 Hi, On Fri, Jun 18 2021, Erick Ochoa via Gcc wrote: > Hi, > > I am having some trouble understanding the semantics of OBJ_TYPE_REF. > I understand that it is made of three operands: > > 1. OBJ_TYPE_REF_EXPR: An expression that evaluates the value to use. > 2. OBJ_TYPE_REF_OBJECT: Is the object on whose behalf the lookup is > being performed > 3. OBJ_TYPE_REF_TOKEN: An integer index to the virtual method table. > > The language here is very general and makes it hard for me to understand. Is > > 1. OBJ_TYPE_REF_EXPR: The virtual function well, it is never the actual function as in a FUNCTION_DECL, it is always a pointer to an unknown function. > 2. OBJ_TYPE_REF_OBJECT: The "this" object > > ? > > Why is the index needed if it looks like the virtual function is > already pointed to by the first operand? As I wrote above, the first operand is just a pointer. Sometimes other optimizations can figure out where it leads but often not (or not early enough for inlining). In some situations we can get at the actual DECL (and subsequently have a direct call) using type based devirtualization and for that we use the other two arguments of OBJ_TYPE_REF. See the big leading comment in ipa-devirt.c. > I am reading Hubicka's post > on devirtualization and Part II > (https://hubicka.blogspot.com/2014/01/devirtualization-in-c-part-2-low-level.html) > seems to agree with me on the example below. There is also no mention > of OBJ_TYPE_REF on part II, but there is on part III. I believe the gimple quoted there has been simplified to make it easier for the reader, since it does not describe the type-based devirtualization but how other optimizations can together deduce the call target, and so OBJ_TYPE_REF has been omitted not to confuse anyone. If you dump the IL for th example yourself, you will see OBJ_TYPE_REF in the earliest dumps and you will see that it disappears as soon as the call becomes direct. Hope this helps, Martin