From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id BBA663858C2B for ; Tue, 19 Sep 2023 14:59:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BBA663858C2B 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-x631.google.com with SMTP id d9443c01a7336-1c453379020so23526605ad.1 for ; Tue, 19 Sep 2023 07:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695135575; x=1695740375; 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=L4aj/JH+oOqQ1hp6J7SRsuh5YU/N4hwNsIwLPaVLRes=; b=RiQKID/qWFIyUgJRDQCx9aSYBzS+GjG1KBu6Z6N4CaD74pe07fvchnrQTpa9xdfCwW hQFxnuDgIcx6EfoDSvAfafo2GKrT50x9nCMSEY5Z6bgxxFuswYvYGUd/vD/rBbM0YQpC 1oCxhFuWkWOYiGlx1F+ydcINo1O2vWYzRveO+vGfOfuRsHHwkHQ9SS08zPZridSheck6 rYVGbjRBM68hWJ5FUXWcF3PG5ZJQrjfw9kIWLf1D9fGl6lsg3T9P//rWepZcPQVpfhDk 7VuEeA/veDIJxDKM3nXN/JNW6euOCZI/ij+FDArJpI6AwOh5nHZNiZlNnHS4T/hJrvSl G48g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695135575; x=1695740375; 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=L4aj/JH+oOqQ1hp6J7SRsuh5YU/N4hwNsIwLPaVLRes=; b=U5DI9Jsmwa8WDLrPuTFS04MDjLtsM05MtjLM3UHGEnrGac9F3p5YOnnJj1eg2dRiG7 1vukAvdurUG7pvGA+8k3C45o3gp6tYWucfXOLw59IwScPeMTeQNKAEevowdiGQTNwwIk RHhScmjubiFV76KWz6zgx766RvkbV7lT2kwQ9cCfCue2XEJrdTKl3vdsZ3BksJrPq0IN W4ti+3gvudxp53ePK1Svyghi/G59U2hQzK1b0VCjHdC1eSNlMnyxJuFAujMNsHM1Dzpo pdgOjUk8s3guaUPBTjgBIebhWlnkJFHFfmATrpzwnGv3CQURKtsaKAaZmV0tOa+iRF+t qTfg== X-Gm-Message-State: AOJu0YyUWSV6HlQKF/73T4FyS7dQVbVr3BWnW23d42UoSaKIJViltzbT vpozTQ5pZkbONFw9vr9MTFopZkIraDfR3A== X-Google-Smtp-Source: AGHT+IEjZKv+keLcypAYik2l8EY6UB5el4DiFLdOdSWoqLOHhVA36xefmIwczP+qIh+dXnrAToHdNQ== X-Received: by 2002:a17:90a:f98c:b0:268:3f2d:66e4 with SMTP id cq12-20020a17090af98c00b002683f2d66e4mr9723938pjb.37.1695135575138; Tue, 19 Sep 2023 07:59:35 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id c11-20020a17090ab28b00b0026b3ed37ddcsm8541750pjr.32.2023.09.19.07.59.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Sep 2023 07:59:34 -0700 (PDT) Message-ID: Date: Tue, 19 Sep 2023 08:59:32 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RISC-V sign extension query Content-Language: en-US To: Vineet Gupta , Andrew Waterman Cc: Kito Cheng , Palmer Dabbelt , Ajit Agarwal , GCC Patches , Jivan Hakobyan , gnu-toolchain , Joern Rennecke References: <24382da5-d503-4890-911a-835d72075372@gmail.com> <96319446-8932-fe73-33e5-75d8ddca788f@rivosinc.com> From: Jeff Law In-Reply-To: <96319446-8932-fe73-33e5-75d8ddca788f@rivosinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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,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 9/18/23 21:37, Vineet Gupta wrote: > On 9/18/23 19:41, Jeff Law wrote: >> On 9/18/23 13:45, Vineet Gupta wrote: >> >>> >>> For the cases which do require sign extends, but not being eliminated >>> due to "missing definition(s)" I'm working on adapting Ajit's REE ABI >>> interfaces work [2] to work for RISC-V as well. >> I wonder if we could walk the DECL_ARGUMENTS for current_function_decl >> and create sign extensions for integer arguments smaller than XLEN at >> the start of the function.  Record them in a list. >> >> Then we just let the rest of REE do its thing.  When REE is done we go >> back and delete those sign extensions we created. > > Forgot to add that even if we were to do this (and the test is doing > this already), REE would fail anyways. It does DF use/def traversal - > starting with use in an extension insn and finding the defs. If the def > was implicit - as in a function arg, it bails out. This is essentially > what Ajit is trying to fix by identifying the def as a potential > function arg and not bailing. > Right. What I'm suggesting is to create an explicit extension in the IL at the very beginning of REE for the appropriate arguments. Put the extension in the entry block. That would make extensions that were previously in the RTL redundant allowing REE to remove them. Then we also remove the explicitly added extensions. Think of the extensions we're adding as expressing the the extension that the caller would have done and would expose the redundant extensions in the callee. We put them in the IL merely to make the existing REE algorithm happy. Once they've served their purpose in exposing redundant extensions we remove the ones we added. If you're familiar with DSE there's a lot of similarities with how we discover dead stores into the stack. We pretend there's a store to each local frame slot in the epilogue, that in turn exposes stores into the local frame that would never be read because we're exiting the function. Jeff