From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id D47E6385B50D for ; Sat, 22 Jun 2024 01:31:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D47E6385B50D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D47E6385B50D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1035 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719019870; cv=none; b=d0fcqtFqHGbk+Zs+gqRdtnSi5yt9HYqNfXLLH1D3XfhT90xoes8cZCMuAnESB4TgmR/LWaqQqgv/WflNgBs9JuLFv4/FCb/mdGHa3vdwnVaidZsgqhpdLq1pV3pk5OyR16di0e2L+nRazZdKopKCybGU2k3WdSVVqoaC9UGmIeU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719019870; c=relaxed/simple; bh=R1NLnM3twbHqyQjzaIo8dJ2rT5un2hHJcM6iRUFlPx4=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=MnumJTAzknAedeG066ojrPmRlTJJc85R0MHOu14Q0c2Y/M6dviXijPg4L8+HGTq3wPT6NYpPJEO88pc6LxF+Wx8HRQQPlYqirxojgWBnARN7uJq9F8ZV0uAMDuKrNoDQvB2L9U2drwrcGJUdF78sKRI7HvrHXY7oXtAeQvE9+Mg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-2c31144881eso2094569a91.1 for ; Fri, 21 Jun 2024 18:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719019865; x=1719624665; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tKa0+n6esYWz6HQkL8F8iFK1nOw6hLqERlaIC2J0ssA=; b=D6PXPrVykLIGJpGUkpAR9qdZpWAI2i+/2OTWxcO+iUtTXVVjv3/H/yGTGhk4Qq7qYi K8SFcDxiQwPdMW2cPY/VAkq0n/+6IreOMgWTE0TUaYJ166sYjO8KknKa1QsBmWKs1Ujl LfGPMcu2wXBbAaxUDHryRabSMaVRG+22v83/q3ZYbwtdtckNAZdQ9QhrgrQ4u2+rZ4lL 6CkMU1geEpNxOabKkzWVft+iqYze6JER07GRJjrTRjA1kE7sfYlbB8CVwr43N+rxpCR4 06/0OCGVKSxvE21dKplMJbB40GtgVEM3tHTGSRA4t83w4oxvNgi9VRjOPqHAgDE01iSq bnog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719019865; x=1719624665; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tKa0+n6esYWz6HQkL8F8iFK1nOw6hLqERlaIC2J0ssA=; b=L0teK6883b3Md3Nqb2HTqoEE49ZkA4KbufdfEf1eYz12aeTKg5xlyGh5bO91qdlJi3 BNOXeNeENbjSxrolU0xwbF1S6OuXqmbm1hnr2pyK7PZsA9D0alZUr+9G6BnJtzw+Q56d ChzZrNJbcyNLYdKzVXO4FjKrlqm4O6pynzaJquFbHA0IP4K8utqz8DmNZdjDLchhV5xz aLnQhlz1CQhPseXwfv6dLAq0VbcAjVdBPBbuglAkPUWX2qssv3tAlf1SLoeYy5pA2cxy EHoBL6Pn+XNIOiIQclccRPI9KoIgTK2ZqyKkp/J2Pg5EhV9p28tWPGTEoXko0aZo0ZYw QJXg== X-Forwarded-Encrypted: i=1; AJvYcCX5d7C/YVjCYpyjnRHGWgyZrLdeqtn9DYtdaUzkfAUDvDbT+VsGbD18Gnn28o5ddChuWCfjbgqwZ75zezh3W+EjBGymcgKrPQ== X-Gm-Message-State: AOJu0Yzf5QhFgPKjbAVx3GaVFUbbPG51V9z3ijyI27s5apJ0YWJvn1O/ k2ULkYrN+CTT/0e7cIa1dabW2/6ddqHO1xL1c9/5OCReqmP5Fpdp9iXpTJ5y3tTqQvcFUc1VKrS vScR2OhrC2gcKPdFELtucxB8KXug= X-Google-Smtp-Source: AGHT+IFSQn02XA6czNDnwxciave7vF0So6BwiKHL7AymFstiESJcLWLvLTRStDWovJT15ZSG5fof3ha5eQFLKghYRdI= X-Received: by 2002:a17:90a:ce13:b0:2c3:16f8:b57b with SMTP id 98e67ed59e1d1-2c7b5cc6b09mr9031421a91.25.1719019864562; Fri, 21 Jun 2024 18:31:04 -0700 (PDT) MIME-Version: 1.0 References: <20240617095336.871176-1-richard.sandiford@arm.com> <20240617095336.871176-4-richard.sandiford@arm.com> <6a7c86b3-d774-4b48-953b-ee0cba090de7@gmail.com> In-Reply-To: <6a7c86b3-d774-4b48-953b-ee0cba090de7@gmail.com> From: Andrew Pinski Date: Fri, 21 Jun 2024 18:30:52 -0700 Message-ID: Subject: Re: [PATCH 3/8] Make more use of force_subreg To: Jeff Law Cc: Richard Sandiford , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 Fri, Jun 21, 2024 at 1:11=E2=80=AFPM Jeff Law wr= ote: > > > > On 6/17/24 3:53 AM, Richard Sandiford wrote: > > This patch makes target-independent code use force_subreg instead > > of simplify_gen_subreg in some places. The criteria were: > > > > (1) The code is obviously specific to expand (where new pseudos > > can be created), or at least would be invalid to call when > > !can_create_pseudo_p () and temporaries are needed. > > > > (2) The value is obviously an rvalue rather than an lvalue. > > > > (3) The offset wasn't a simple lowpart or highpart calculation; > > a later patch will deal with those. > > > > Doing this should reduce the likelihood of bugs like PR115464 > > occuring in other situations. > > > > gcc/ > > * expmed.cc (store_bit_field_using_insv): Use force_subreg > > instead of simplify_gen_subreg. > > (store_bit_field_1): Likewise. > > (extract_bit_field_as_subreg): Likewise. > > (extract_integral_bit_field): Likewise. > > (emit_store_flag_1): Likewise. > > * expr.cc (convert_move): Likewise. > > (convert_modes): Likewise. > > (emit_group_load_1): Likewise. > > (emit_group_store): Likewise. > > (expand_assignment): Likewise. > [ ... ] > > So this has triggered a failure on ft32-elf with this testcase > (simplified from the testsuite): > > typedef _Bool bool; > const bool false =3D 0; > const bool true =3D 1; > > struct RenderBox > { > bool m_positioned : 1; > }; > > typedef struct RenderBox RenderBox; > > > void RenderBox_setStyle(RenderBox *thisin) > { > RenderBox *this =3D thisin; > bool ltrue =3D true; > this->m_positioned =3D ltrue; > > } > > > > Before this change we generated this: > > > (insn 13 12 14 (set (reg:QI 47) > > (mem/c:QI (plus:SI (reg/f:SI 37 virtual-stack-vars) > > (const_int -5 [0xfffffffffffffffb])) [1 ltrue+0 S1 A8])= ) "j.c":17:22 -1 > > (nil)) > > > > (insn 14 13 15 (parallel [ > > (set (zero_extract:SI (subreg:SI (reg:QI 46) 0) > > (const_int 1 [0x1]) > > (const_int 0 [0])) > > (subreg:SI (reg:QI 47) 0)) > > (clobber (scratch:SI)) > > ]) "j.c":17:22 -1 > > (nil)) > > > Afterwards we generate: > > > (insn 13 12 14 2 (parallel [ > > (set (zero_extract:SI (subreg:SI (reg:QI 46) 0) > > (const_int 1 [0x1]) > > (const_int 0 [0])) > > (subreg:SI (mem/c:QI (plus:SI (reg/f:SI 37 virtual-stac= k-vars) > > (const_int -5 [0xfffffffffffffffb])) [1 ltr= ue+0 S1 A8]) 0)) > > (clobber (scratch:SI)) > > ]) "j.c":17:22 -1 > > (nil)) > > Note the (subreg (mem (...)). Probably not desirable in general, but > also note the virtual-stack-vars in the memory address. The code to > instantiate virtual registers doesn't handle (subreg (mem)), so we never > convert that to an FP based address and we eventually fault. We should really get rid of the support of `(subreg (mem))` as a valid for register_operand (recorg.cc). Two ideas on how to fix this before removing `(subreg (mem))` support from register_operand: 1) Maybe for now reject subreg of mem inside validate_subreg that have virtual-stack-vars addresses. 2) Or we add the code to instantiate virtual registers to handle (subreg (m= em)). Maybe we should just bite the bullet and remove support of `(subreg (mem))` from register_operand instead of hacking around this preexisting mess. Also see https://inbox.sourceware.org/gcc-patches/485B2857.2070003@naturalbridge.com= / Which is from 2008 about this subreg of mem. Thanks, Andrew > > Should be visible with ft32-elf cross compiler. No options needed. > > Jeff > >