From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id 62D2E38582BD for ; Fri, 31 Mar 2023 14:01:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 62D2E38582BD 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-pj1-x1033.google.com with SMTP id h12-20020a17090aea8c00b0023d1311fab3so23431750pjz.1 for ; Fri, 31 Mar 2023 07:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680271289; x=1682863289; 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=6G0iKEzuOMzP2CX0wCYQcQB4gsKkE16TuosCMrnPoiY=; b=IvCyvQIm3pcSFxUNlBEzovajvxr1/8KsmlhDyYzmLMnhyHdjDboMh/gu8sxDBa6yDk /LDQ0uQnAppNs8aosevtxGeXiGhUGOP6aTTAKAliZN8fUJOpueiEngXAWCMjHHHk55Ay hQ7yO7sskoCy/SHTjtkfPt6KcdweU4Iywx8TZhvHZARp/YmfM9m9jzNIlOcTAhL08JxA y07SRoE7cSL3ItUh+azc4MQseC3kgSzIa3dNmn1wHgYkE8ry823nJJ8sV4VIT2/JRPKy FrWKtHaX8i8ly5KjyQ8dHtfATlQW53ltu5mSziOEWYT/RI3XdhWDSg3/EyE28ChyZb5i 0u6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680271289; x=1682863289; 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=6G0iKEzuOMzP2CX0wCYQcQB4gsKkE16TuosCMrnPoiY=; b=2iFYTNdM0C9qPFGVkK2OISBWRtMqZalC/PslpceXHnUatmzcfCVqBIKYIM4iu17pYX 569hkPc3ERYboMJKV+TpvwST0kWGHbJ4lxVXzdvDX5YRL4MXMdq2swPDWG472TyOEQYk 1JGPI+Wzvkiop7Niewm/xN8BCr/jNRrQTB1qkTMp4WqPzQMZ9WNaD6QvWmvLr80nGFZO YLtH6Czu34oR/M+O0SFW/K9tGpK8Agd3M2mOLm+XZ3uXId/dsx7ppjCfWqq2x9cRRpjb C8NXPTW4GGR6bccE/1jYEt0+WL0F0fQ3IAlJA3SfHmlR+qXtquHl2zi4ktrlLzNe8yDy rCOQ== X-Gm-Message-State: AAQBX9dfifVjOUTmqUnlqje68A3N0nFTX7cCgk4l5gF/t4AEG3+p49Hz 44/PX2qEgoBzOAVGa0z75u4= X-Google-Smtp-Source: AKy350aQFCnDbC51vN6VHnPBThDpmdXqoHPbybeVrBi6jnwNsS8Ayuj2+S7KmXVQBRBMSaMFMmjM2w== X-Received: by 2002:a17:902:e810:b0:1a2:35f3:3608 with SMTP id u16-20020a170902e81000b001a235f33608mr29285840plg.49.1680271288321; Fri, 31 Mar 2023 07:01:28 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id n24-20020a634d58000000b0050f9b7e64fasm1567242pgl.77.2023.03.31.07.01.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Mar 2023 07:01:27 -0700 (PDT) Message-ID: Date: Fri, 31 Mar 2023 08:01:26 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension. Content-Language: en-US To: Hans-Peter Nilsson , Peter Bergner Cc: Ajit Agarwal , gcc-patches , Segher Boessenkool , Richard Biener , Raphael Zinsly References: <4c0b6b4f-bbc1-8dd0-a91c-ffed028b4873@linux.ibm.com> <365cfb50-4313-d44e-6ffc-77473b20c670@linux.ibm.com> <5834b0cb-dd25-c55f-2cf6-9aa6b8372724@linux.ibm.com> <29ab8ff7-20d5-183f-a0ce-c82758488b64@linux.ibm.com> <1a482ac5-404b-0787-c682-b10d13dc76ee@gmail.com> <247f5af3-5db3-4a73-b636-95e006a3a649@linux.ibm.com> <0caf5e53-76e2-afc6-8b8c-363e56cd8212@linux.ibm.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.3 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 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 3/30/23 18:01, Hans-Peter Nilsson wrote: > On Fri, 24 Mar 2023, Peter Bergner via Gcc-patches wrote: > >> On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote: >>>>>> Is there a reason why REE cannot see that our (reg:QI 4) is a param register >>>>>> and thus due to our ABI, already correctly sign/zero extended? >>>>> >>>>> I don't think REE has ever considered exploiting ABI constraints. Handling >>>>> that might be a notable improvement on various targets. It'd be a great >>>>> place to do some experimentation. >>>> >>>> Ok, so sounds like a good follow-on project after this patch is reviewed >>>> and committed (stage1). Thanks for your input! >>> >>> Agreed. I suspect that risc-v will benefit from such work as well. >>> With that in mind, if y'all start poking at this, please loop in Raphael >>> (on cc) who's expressed an interest in this space. >> >> Will do. I suspect that it'll be best to come up with some generic interface >> using target hooks like "param regs are sign/zero extended" or "call return >> values are sign/zero extended", etc. that targets can conditionally opt into >> depending on their ABI that is in effect. > > Pardon the arm-chair development mode but it sounds like > re-inventing the TARGET_PROMOTE_* hooks... > > Maybe just hook up TARGET_PROMOTE_FUNCTION_MODE to ree.c (as > "you" already already define it for "rs6000")? > That's what we touched on up-thread. Ideally we want to wire up REE to utilize the existing mechanisms to specify ABI constraints so that we don't have to write all those macros again. jeff