From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 02B963858D28 for ; Mon, 11 Dec 2023 06:02:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 02B963858D28 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 02B963858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::432 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702274578; cv=none; b=lsRPt+eQ7Y1tL/ANYiSx5zNAex297uxlHvodwnsZplz3AlFHufmpslodqqSUez4jNcrWAzFMR2s7MmW2MBLlJ1R4xw17Vt3e2zAealGE2SKgrroY15URmf4aIGvgfaoa85feFlIlqvMqzbsef1GTxoCDC3YX2le4TyedqJII28c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702274578; c=relaxed/simple; bh=R9mwa360Dyd66Wn8wAzqCt0njG/3YWsfVI2tLvAEFhI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=gaxvblRhZ1R8XlGEiokAWytBhI4yp2sI37OFJHcFxuQZCAL3ICTWAmriHWal2MTfrlXYlhdH9NLTYPtBrQ0RoZdS+8gT5KdzCiW/CPjGR1VEu/T6Vo5akHKfl7y7SzYKheHVzICoWBWPuBqidpstN2zmHx/7Jt956TPUEVUIKzo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-6cda22140f2so3463069b3a.1 for ; Sun, 10 Dec 2023 22:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702274576; x=1702879376; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=lnvXmtTOKnMdgTJEp/kSytinP9Q/s0ekQ+IOOBFG6CU=; b=aRQEJQaoMyzdVtD0+yBHa/ROJmaxihoTmvnOC3MiB/IL6yo29jnyu/OwQFsle3YkbZ vD4qKCLtxpIQrs7TEIEAynREcsPUngFZ4zC8p/quGfYhGDdK2QslSkovVp04pUQSAWeB Yo96/hpTKcsTNh00Yi3dLu+CAvnKpQqlpW4nGS812ciQUTbWOHv1dz0XCjiLFBD0IwUf Lt3N3Boyw49+XXoXS/tW0LcsxpoComDr0SNLSCHaAqRm9eSY/ZtA3egBQbUosMYvUVwn 7H6oejTR2JwaRgKz7YzbeB4zM5lVOLFa1JQ8sQlrxCuqOiCdvMfuP13MZMxA8jDcni95 cewg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702274576; x=1702879376; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lnvXmtTOKnMdgTJEp/kSytinP9Q/s0ekQ+IOOBFG6CU=; b=hTORSywV1AH/xPsukEDVAsWTzwRaSwpFrYFtSC8PNJPU/cRm/O3z1L940s4daQ1SdK b3J5hd7HgBxvoF/YlChH9iuSK6wdhQjnA32DwEAcq4PEWUHKz2q11PDgxtGBfWWE6orU c4An5rUBcDgo9KTeaypCI2iRG8KYB8C6wsM+W7kagR3ooaxGuvqfrvsMhQeIMrW3MhYc l/i24aBafs2mfDNk/ht/CH0XUrsRMljFZTQamc5VXofAaozOa5cmYGzTYY2fJb3+KX03 yLf2vfvmarXnhoHxNOENlKKJZgBIq/cvybFVRWsa6fYdlJucFV9kACjInkxNUxUm0Tvw HsRg== X-Gm-Message-State: AOJu0Yw8gMpY/M2zBc1u1+npzNMDGmjhLA8b1NiPvJFD3niPj1kiJ+v9 DL3JWjs7wPbBruicOestWVrGbSwlSsM= X-Google-Smtp-Source: AGHT+IF7o9T9ATMKPIKYGkcwrNOttZbV6eH9r2/9GQr9OOznGWfL+eJgoLUrf2YFiMkAE9c1mzkTCw== X-Received: by 2002:a05:6a00:10d3:b0:68f:d1a7:1a3a with SMTP id d19-20020a056a0010d300b0068fd1a71a3amr4367197pfu.8.1702274575614; Sun, 10 Dec 2023 22:02:55 -0800 (PST) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id p4-20020a634204000000b005b856fab5e9sm5425936pga.18.2023.12.10.22.02.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Dec 2023 22:02:55 -0800 (PST) Message-ID: <82af71f2-06ee-416d-b6b0-3f42448b3733@gmail.com> Date: Sun, 10 Dec 2023 23:02:49 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] -finline-stringops: don't assume ptr_mode ptr in memset [PR112804] Content-Language: en-US To: Alexandre Oliva Cc: gcc-patches@gcc.gnu.org References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 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 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 12/10/23 15:38, 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. I'm not very familiar with ptr_mode. I do remember that Pmode can ultimately differ from the mode that you'd get from turning POINTER_SIZE into an integer mode. For example we might have Pmode defined as PSImode while POINTER_SIZE is 32. That was the model used on the mn102 as pointers were quite literally 24 bits in a register. > > > 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 (== pointer_mode), and that's the address stored in addr and > 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 = targetm.addr_space.address_mode > () = 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? Not terribly fishy. Mostly I think I just wasn't aware of ptr_mode. It looks very similar to some of the kinds of bugs we found on the mn102 way back in the day and since then we've grown some infrastructure to handle it better. OK for the trunk. Thanks for walking me through it. jeff >