From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 135DD385841B; Sat, 10 Jun 2023 17:40:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 135DD385841B 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-pl1-x62b.google.com with SMTP id d9443c01a7336-1b3a9eae57cso2701625ad.1; Sat, 10 Jun 2023 10:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686418847; x=1689010847; 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=iGnGOdzIE1U1uXSgrCZmt85wCnWrQUv1VmVR7LZK420=; b=Xs3yBvO3Ku5R86jpGsCRY85Cv86RxeOL7anuh8S+cUKcfo5EQslaSGpqO58TqEA/if Kwe+W9FvB4o1zV0yxzRTiCHd2/Ok3+uXGuV45Xac4R8jDWZImXkqlp8T7IdPFkk09Wo/ P93PRc/XfmktS9gU5n8CIOKGyTWVbHhgzDRLHyoHzeuOuHV/Rhnq/c9FI2vIWH2CUExs G1hOJ/53PB9lrwuz6OHiSP+hSNDiFuESf2d1PmIQO5m9CgLY9FEzRk3pIunnvDFHzUw/ KFNJMj4V2efFXPwa1b4N1d4D/HVO+pdItGE2GwqRiZ2htFK9bpPNNcuVhwHmaKesRzFy R+iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686418847; x=1689010847; 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=iGnGOdzIE1U1uXSgrCZmt85wCnWrQUv1VmVR7LZK420=; b=RQg0NVnApGke+CYMEVCDeRdo/gBX0FzAC5Jj7+L6FWn8DpIe8BrUcnBwb+ELQQTGk1 YLibQkdxCXOtmL/xvp4OFZYYayJTXu5JsEVfgKjpCLrWvLSO9kKISbf4hud/+amIkQUu neIm/RTN4a+Xf1Cj2S1Qd5WlWgxo/0HRi2JYnpaczgJ+78/zvXDy7nkmswYECFPhPAhe X4sADhuvPrcAvY8M1aLuMHz6uAW6+ApKVIVuS6OUUM1lP0ssGfIGyyBcvQ1Hvx9E1dfs /cmHh17oTSdo0IzjNysiosyhaUIlEZ4t2tPbiYhE692wVL0REUv0R9Qpt9zw9oNLDfbb hf0Q== X-Gm-Message-State: AC+VfDwqgpzjvPLqDxKqrMC5IcpKamIuFPdfjMBCBo0tLY4GinS6E0X5 GttltiJYcv6t6xEDuA3Dv+4= X-Google-Smtp-Source: ACHHUZ6mAwAPrjymdRbNi0SVUaxSVnbSFGeM25llilznG8bgAB+uBv8XuZNRLSW3pRkbNSocpJIFfw== X-Received: by 2002:a17:903:1103:b0:1af:e302:123 with SMTP id n3-20020a170903110300b001afe3020123mr3049719plh.3.1686418846810; Sat, 10 Jun 2023 10:40:46 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id s9-20020a170902a50900b001a505f04a06sm5226290plq.190.2023.06.10.10.40.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Jun 2023 10:40:46 -0700 (PDT) Message-ID: Date: Sat, 10 Jun 2023 11:40:44 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: Ping^^: [PATCH V2] extract DF/SF/SI/HI/QI subreg from parameter word on stack Content-Language: en-US To: Jiufu Guo , Jiufu Guo via Gcc-patches Cc: segher@kernel.crashing.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, rguenther@suse.de References: <20230104134557.196235-1-guojiufu@linux.ibm.com> <7nilfjlcow.fsf@ltcden2-lp1.aus.stglabs.ibm.com> <7nr0rnbr5q.fsf_-_@ltcden2-lp1.aus.stglabs.ibm.com> From: Jeff Law In-Reply-To: <7nr0rnbr5q.fsf_-_@ltcden2-lp1.aus.stglabs.ibm.com> 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,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 5/10/23 19:20, Jiufu Guo wrote: > > Hi, > > I would like to ping: > https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609396.html > > We know there are a few issues related to aggregate parameter and > returns. I'm thinking if it is ok for trunk to use this patch to > resolve part of those issues. It looks like the patch is focused on emitting a load of the object from memory into a GPR, then copying the GPR into pseudo (which hopefully gets allocated into an FPR). That would seem to indicate the value got flushed to memory at some point. Presumably because the type of the object it not one that we would typically allow in registers, except for some special cases for parameter passing and return values? If that's the case, then is there any value in finding the flush to the stack and just emitting a copy from the GPR into the destination pseudo at that point? Or is it just easier to construct a load from the flushback area and let CSE/DCE/DSE clean things up? Jeff I