From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D930B3858CDA for ; Mon, 29 Jan 2024 12:21:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D930B3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D930B3858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706530871; cv=none; b=djIxOQgvXe2hMJlRDtASCxaQHuToSzdHCDufh06366xo475R0DdoO8CBRwE2iZ+NTgu7QJiXHNb1GLPdFc7xFFQGkbgNxlY1DGFSW4U/yZmWYYu8+U1ZZAAHdaaO918IQkqUb4riKjq/ZLFCcmydJpa+e6gyGKSGNJXhtJr5sns= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706530871; c=relaxed/simple; bh=pvM6W9k27Sx6RMznJnh/1kTtcHxh+TYmP2AF6YfarBg=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=ZPskFsYNot/3+uJehZS5s7nusvP8gd0APaW9iN5WsvRgKBorAGXLgodlaTiwmi/Ub9EvpztxBlUT2IBxJDdv4XHu+5vrKT9tBohI623wrAwdc+gIYP9BuZfq7Yg48T7zPdfFbDu65uDxyIyADCT1MplE9vuLU2oG73YG/foABAc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1706530869; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=M0+Arc+SwfvdQG7jIh6UZGDiTXOX0Af5h+uDGUWwL2U=; b=RGkuVX/h9Fc27kWzVxyOqbyhcWO0XDks6rrIeY5X39KcvqwCt0TIHD4pQ8h+Bs5zU7KaMI tGkBvAJ+x9UXrcuVGhhbHraATT1aEFhg46WQ0CmK4zmJbFzRpOaymA3jc58iRELV8r5anp IqP8Rkn7lFLHJ10etPRBNiyEc3UPX4s= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-29-qNRWL5TYNGyM2cRuaPPBeQ-1; Mon, 29 Jan 2024 07:21:06 -0500 X-MC-Unique: qNRWL5TYNGyM2cRuaPPBeQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B65EC1C07F22; Mon, 29 Jan 2024 12:21:05 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 78B5A1C060AF; Mon, 29 Jan 2024 12:21:05 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 40TCL36K2973913 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 29 Jan 2024 13:21:03 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 40TCL2aC2973912; Mon, 29 Jan 2024 13:21:02 +0100 Date: Mon, 29 Jan 2024 13:21:02 +0100 From: Jakub Jelinek To: Richard Biener , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] middle-end/113622 - handle store with variable index to register Message-ID: Reply-To: Jakub Jelinek References: <04221.124012907112600441@us-mta-365.us.mimecast.lan> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Jan 29, 2024 at 01:17:16PM +0100, Jakub Jelinek wrote: > On Mon, Jan 29, 2024 at 01:05:51PM +0100, Richard Biener wrote: > > The following implements storing to a non-MEM_P with a variable > > offset. We usually avoid this by forcing expansion to memory but > > this doesn't work for hard register variables. The solution is > > to spill and operate on the stack. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK? > > > > I realize the flow is a bit awkward, but short of duplicating a lot > > of code I can't see a better way. Forcing some lowering on GIMPLE > > (creating the copy there) might be another away. But then we > > could possibly lower the whole vector indexing in a different way > > in the first place ... > > > > Thanks, > > Richard. > > > > PR middle-end/113622 > > * expr.cc (expand_assignment): Spill hard registers if > > we index them with a variable offset. > > > > * gcc.target/i386/pr113622-2.c: New testcase. > > * gcc.target/i386/pr113622-3.c: Likewise. > > Ok, thanks. Actually, better to do gcc_assert (VAR_P (tem) && DECL_HARD_REGISTER (tem)); Again, nothing guarantees tem is a VAR_DECL. Though, with tree checking it would either ICE for DECL_HARD_REGISTER (tem) being false on a VAR_DECL, or in checking on tem not being a VAR_DECL. But say with release checking it will do a weird thing. Jakub