From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id E9B193858C2B for ; Sun, 10 Dec 2023 23:01:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E9B193858C2B 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 E9B193858C2B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::102f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702249283; cv=none; b=bPALcN3I4pMdFvbaQH1on2Wtx4yRLbCwVQP5urKeWR2CytgJxgmgoCaU13hhnQBUEY/xqsHiNUvUtL8fgR0N9TcPp3Zmvang3S0OYLunTBjTirAfMYNJh+4UMjkCdx7VHclinP1stZol500OUnG180CKfaII2VDNEUUytt9Hn10= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702249283; c=relaxed/simple; bh=9t+hlQ1cJ8VzC7qRDtaIeAbxLgWpkswMFAYklmURjhk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=XQsioPZSjEVav6FJ7a4X2bH9hF7zgD3GynZ2dlABz9lZZqp0IWrXVmoAXVEc4JQXYPkGoErFf+T36VZpw3VIqrBDyCZs27v+z7pgZWLpAv8iAYqTdGJ+ne1F2GR+hAUXJaPWp3Yji3lv6KNTR+MUUgPjCIF/gq9bM7x9SQhKD1U= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2851a2b30a2so2720378a91.3 for ; Sun, 10 Dec 2023 15:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702249280; x=1702854080; 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=24pBcwIwF7vEn4gB7sMKuLHmmll/tbBHBkqj+Z18dG4=; b=AS5xs+zU2Jdnjxd0FGQXSxL0ReXbOnU/TBI5etrQfp0QBKwaPF1QkdM/fP2HcD/1XA hNKLJHSnVRQgW9EPaaPDhIQXbKLWGhsgPOI55jtBXoRYMbC44qeZ5XcYACb9+JcBjVxR dStvNQA+THE5CrAw0Y4XpTEYBujVGjUF0jtnx114Fy7y577zgr4MWI6LWQG+wjmVwe3T YviQGn3RyUH8LAos/ysuOXHG6h7nTQUfsiuRArryl9NIypeU+yBWX4zJTUS8TDV+UlEJ 9qXoJbw0S7sf2ZQB75lDQxUFM3fdsGlfyO9j5uGqWTBOM2WsHWtQyJB8Z4sHGlebXcjw W76w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702249280; x=1702854080; 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=24pBcwIwF7vEn4gB7sMKuLHmmll/tbBHBkqj+Z18dG4=; b=gIhKYs/6r3Fdng25M2oKVS/aU9QV6B45JkBmQMGvLWp9X7LzSfb707w+4qkCqQxLMU p2UQ1T0hqYwMLLLGx7dVejqFPBqG0i+wuV37md7se6CPcWD5cpNytPfy+GGMBCyeI8bL sGlXDZb/TR7NC2C2oPXiXBw83HqjVlblmq/6SDoGHQsPTrEFPwsdwFePHrEYxgZuYYUF R86whinaP8OhMTgx3vdoJv5ZPpkC2dh7YlkgkOowAHKLTGTx3lRhf5YSEnRgBgqY+XSv kGEdeMaz9tjRzog5vO8ovSKjGvJpRwqrPf/TNKBdBk12jYk6gGHqbkdTiSOrhOZevBi5 9Lyg== X-Gm-Message-State: AOJu0YyEvZ68VeWFbAXmZIXD/I8jeEjSl8FXvWpk/UB36sxsUDKlfF56 94UTmMFcKK1iymt6ms85S9LhrjBCtFnVD2JwbjY= X-Google-Smtp-Source: AGHT+IFYpx6ARKl/gcdiRNAvWVmEZiZXZYkMpn8BoHaVC/VgvkBQe90TQdsqBhGOQeVhKdpG1Tp60vUvWie6Fjn2wa4= X-Received: by 2002:a05:6a20:8f28:b0:18b:f108:1595 with SMTP id b40-20020a056a208f2800b0018bf1081595mr1874100pzk.53.1702249280505; Sun, 10 Dec 2023 15:01:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Sun, 10 Dec 2023 15:01:08 -0800 Message-ID: Subject: Re: [PATCH] -finline-stringops: don't assume ptr_mode ptr in memset [PR112804] To: Alexandre Oliva Cc: Jeff Law , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_QUOTING 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 Sun, Dec 10, 2023 at 2:38=E2=80=AFPM Alexandre Oliva = wrote: > > On Dec 10, 2023, Jeff Law wrote: > > > On 12/8/23 19:25, Alexandre Oliva wrote: > >> On aarch64 -milp32, and presumably on other such targets, ptr can be > >> in a different mode than ptr_mode in the testcase. Cope with it. > >> Regstrapped on x86_64-linux-gnu, also tested the new test on > >> aarch64-elf. Ok to install? > >> > >> for gcc/ChangeLog > >> PR target/112804 > >> * builtins.cc (try_store_by_multiple_pieces): Use ptr's mode > >> for the increment. > >> for gcc/testsuite/ChangeLog > >> PR target/112804 > >> * gcc.target/aarch64/inline-mem-set-pr112804.c: New. > > Hmmm. I'd like a little more information here I wouldn't expect those > > modes to differ even for ILP32 on a 64bit target. Are we just > > papering over a problem elsewhere? > > Possibly. I've run into Pmode/ptr_mode issues before, so I didn't give > it much thought. > > > Despite ptr_mode's being SImode, and DEST being a 32-bit pointer, > expand_builtin_memset_args gets from get_memory_rtx a (MEM:BLK (REG:DI)) > > The expansion of dest to RTL is convoluted. It is first computed in: > > (set (reg:DI 102) > (plus:DI (reg/f:DI 95 virtual-stack-vars) > (const_int -264 [0xfffffffffffffef8]))) > > in DImode because virtual-stack-vars is DImode, then it's > SUBREG-narrowed to SImode in expand_expr_addr_expr_1 because of > new_tmode (=3D=3D pointer_mode), and that's the address stored in addr an= d > passed to memory_address in get_memory_rtx. > > But then something unexpected happens: memory_address_addr_space extends > it back to DImode because address_mode =3D targetm.addr_space.address_mod= e > () =3D Pmode: > > (set (reg:DI 103) > (zero_extend:DI (subreg:SI (reg:DI 102) 0))) > > and it's a MEM with (reg:DI 103) as the address that gets passed to > clear_storage_hints, and then try_store_by_multiple_pieces, where the > address is copied from the MEM into ptr, and then, in the update_needed > case I modified in the proposed patch, it gets incremented. > > > So it looks like my hunch that this was a Pmode/ptr_mode issue was > correct, and I don't see anything particularly fishy in the conversions > above. Do you? That looks correct. Just for info; AARCH64:ILP32, even though the exposed pointer size is 32bit, the address for the loads is always done as 64bit. That is why there is a difference in Pmode and ptr_mode here. So Pmode still needs to be 64bit due to the addres requirement while ptr_mode is 32bit. x32 on x86_64 implements 2 different modes, one where Pmode=3D=3Dptr_mode and one where they differ. The default for x32 is Pmode=3D=3Dptr_mode IIRC. This is because x86 has load instructions which handles addresses that are 32bit (zero-extended IIRC). IA64 HPUX has a similar mode to AARCH64:ILP32 but I doubt anyone tests that any more or even supported; it is also where most of the original testing for Pmode!=3Dptr_mode happened. PowerPC64 has a mode where Pmode=3D=3Dptr_mode=3D=3DSImode but word_mode=3D=3DDImode; this kinda works on Linux but if you hit a place into the kernel only the lower 32bits is save; it does work fully on powerpc Darwin (Mac OS X) though. Thanks, Andrew Pinski > > -- > Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ > Free Software Activist GNU Toolchain Engineer > More tolerance and less prejudice are key for inclusion and diversity > Excluding neuro-others for not behaving ""normal"" is *not* inclusive