From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id E47733858D35 for ; Sat, 24 Jun 2023 14:32:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E47733858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-553a998bca3so1334395a12.2 for ; Sat, 24 Jun 2023 07:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687617138; x=1690209138; 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=KnWVcX7Uf/O/+YviVFr9mL6wzeJFCNCma8pFG3rBk4M=; b=I5wL+0Gx0zkD1Y21UUMSbKjyuXwliGeafCseJ6DO1gz14ZdD1DnvMK2VwZH9fFKSDu kfv0uSU5oC31ij1BoJv5wz9rUKF84B/RX/SEx0DOe3dyZCtILL+NA6ti99g5sLctm5LT 7288/gFPJhl23fHLOzwIT71hW9AppvSpNNzFpKHXwyK8VqLyg6Gz/92XKF4qjNRln0Nh xFSuNp6RUK5FAW4t4pFQrT7PCrqqJ7oNqP5X7Q2HKN99ouRGcyOFZejgaCQ8IVShEhnV wWu83L3xPU0LfISiPLQ2TwT35+sJK0aly91F17eUOr21BYnA45yuFfMCKIwZKYIaKU0P 2cuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687617138; x=1690209138; 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=KnWVcX7Uf/O/+YviVFr9mL6wzeJFCNCma8pFG3rBk4M=; b=lQIVeDBinvrEPY9hqKlOuSovqrb2stiTcQSwmJ0HEWf8hZDoiLHGSwPkzGzvj/kf13 kK6OVxvQHyDnvKum0d9sGp0rFv3qxQLfxi69XhAleGsM56AgLIatmTHfDTF5YBMWCu1T b8UZQ7xXT+lfSEW6/NnDsD1WX80ngoFRZmKxrKGbldYGhY6EUfcSH/JxFd21XAW5Nhk2 r0cY38uaUvmoAyaNsGA2mTKYFmRjCOft+pj+uhtlr8RwBhaV9mgUN3+mVgC0ImjoCik+ 4BZ2wOmhp54dJF6CPgOtMi4BytwEqUF721PEOMKEbblcMzisiA3kMVLOXx4DaVIIlRol RAQw== X-Gm-Message-State: AC+VfDxdWOqeDoAxpCD4QVVaUN7G5Akwt1j6spYd1Qypr+iyQ6N9q2TX 2Se7lElZ7tI5dvTspH9f8YVo7zcdOCU= X-Google-Smtp-Source: ACHHUZ6I1nN4vQkl+EtKh/mDixwGJhKuF4LE17gRzlNq40BM8pTAL3cRvEcoGWNctVhtWX9smQZ+ig== X-Received: by 2002:a17:90b:3509:b0:25e:f6bf:badb with SMTP id ls9-20020a17090b350900b0025ef6bfbadbmr18037443pjb.4.1687617137812; Sat, 24 Jun 2023 07:32:17 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id w7-20020a17090aaf8700b0025e9d16f95bsm1420453pjq.28.2023.06.24.07.32.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jun 2023 07:32:17 -0700 (PDT) Message-ID: <17b75333-9eac-603d-4f05-cae793dd6f76@gmail.com> Date: Sat, 24 Jun 2023 08:32:15 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH][RFC] middle-end/110237 - wrong MEM_ATTRs for partial loads/stores Content-Language: en-US To: Richard Biener Cc: gcc-patches@gcc.gnu.org References: <20230621074951.F3C3C3858433@sourceware.org> <08e73abd-ecb0-1b5c-6f78-f4c53d095f0a@gmail.com> 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,NICE_REPLY_A,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 6/22/23 00:39, Richard Biener wrote: > > I suspect there's no way to specify the desired semantics? OTOH > code that looks at the MEM operand only and not the insn (which > should have some UNSPEC wrapped) needs to be conservative, so maybe > the alias code shouldn't assume that a (mem:V16SI ..) actually > performs an access of the size of V16SI at the specified location? I'm not aware of a way to express the semantics fully right now. We'd need some way to indicate that the MEM is a partial and pass along the actual length. We could do both through MEM_ATTRS with some work. For example we could declare that for vector modes full semantic information is carried in the MEM_ATTRS rather than by the mode itself. So it falls into a space between how we currently think of something like V16SI and BLK. The mode specifies a maximum size and how to interpret the elements. But actual size and perhaps mask info would be found in MEM_ATTRS. jeff