From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id DD1BD3858C54 for ; Tue, 28 Nov 2023 13:13:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD1BD3858C54 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DD1BD3858C54 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1036 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701177200; cv=none; b=CTcCqr2yCepFqP+pPmLrVaeu5M7/4lyetYoCvhq875s2NPM0CE74CpeY/BvNejLgIwDYDSjfFi/G2j+pnZfi4FNquP1B/fmrquVQRJJ2D7ud4QzgkcF8DpZA0luwRqvCPCcU6wQmd7AQj1/28KMgV4lTYKOtYD6CkrJi/B1nkps= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701177200; c=relaxed/simple; bh=9YXvRIJ2DpmAIgpEi7COuNMKK2PID1b3H+fGPja50Zk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=p0pO5TqhCRnI3A1z8eA1QYsQiGNhGPtYJN9qM76AZEni/EsJPEA4cdM5eIYQ6O8cQxrOEWzZZDBXEa78xfqYmY3tooKdUo8mvZbs35moyPJw9rvS1hUWYaASfI1zuPnn/C7lUvikpVymv+jikYq3Udeg6oFhl4xFRkYHxMtWMqw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-285c3512f37so2247040a91.3 for ; Tue, 28 Nov 2023 05:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; t=1701177198; x=1701781998; darn=gcc.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=jmtayVvfy4xHzrQ0AfAK6b+D0XeXxaHMbFuzUkF3CuE=; b=FB6U3yNGzri8YHSckZp1nnaOIL81aMrnG6dmA1JoIwTJWn2wlmMBaFA/FTYTIZUw6X kHohrp9wRmFMpr+4iUeIreGy3kKEw8QJ4PGlqsY4jnQ3N/SYzS1xuMFl5acm3ITlcVIB p+GEGXhvYjKX+7pVZHpvroZYgkAfMYTEjmoUoFRMYE5J6c0E9/ZaoAMzWglT91WvvxQc m/T+NQ/+zqba6ATBk9zZoBjjdzMBI73ppGoXrJ3sfBamsiR+eXGfRuHZj1lt0K8c9/zV qgGAa5W8XOM/ibY5K2pIQzQBpDDnVJ0etFxDXgWCrAXHy1t6xVSuJXwN2M7dY7iXh4jV aNtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701177198; x=1701781998; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jmtayVvfy4xHzrQ0AfAK6b+D0XeXxaHMbFuzUkF3CuE=; b=QlQkDdzbHe3u7J4Z3+kBSxQIHmEDyQMdic1aH+s81tHc7JQfXgFbIhCMXz+oOBCjyu SXdhhGp4VVkHVTzc678Enm29IRVVp3vX+JLhIfajIgZ9WtAeP84L2bwFnC4+S3awBK32 +S9BwI9ktMp08IaUOsBEtcEaec2+3QIim7ffpnrDBZPCHj0nDRbruwGF1bN3R++LjoYL k/woAPsTQmOxCwgl1kfpARR2TsuJoYedRIvAuLILdgzOJVjMCeLtZChdDFju/x7PmA8V TkLzCQ71pDMGwCcZbQzqNDRVviQMnMkQPecqWCnWrxLTxumkXHbuYN0Fz7iNZllr2Gtj Dw3A== X-Gm-Message-State: AOJu0YxGw+75+gAO1epFfk+1QrvRZ7JMdqOzUBXEjgtwx7dKr4NFTxWL Gtw2BtC2sn6Bp5JiNm0zai86ZAVfFb4Kx7+whG1ILA== X-Google-Smtp-Source: AGHT+IGOi4Nwzrcx4wzYe+g0xVlJqZyxLI3kHDpJDS/5BwaBPjbdAbeyeqMZVqQrxsYHdZIm2tWQVFMmxzZNNVY+eSo= X-Received: by 2002:a17:90b:391:b0:285:afcc:e667 with SMTP id ga17-20020a17090b039100b00285afcce667mr10961618pjb.27.1701177197869; Tue, 28 Nov 2023 05:13:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Joern Rennecke Date: Tue, 28 Nov 2023 13:13:06 +0000 Message-ID: Subject: Re: [RFA] New pass for sign/zero extension elimination To: Joern Rennecke , GCC Patches , jlaw@ventanamicro.com, richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 Mon, 27 Nov 2023 at 20:03, Richard Sandiford wrote: > > Joern Rennecke writes: > > On 11/20/23 11:26, Richard Sandiford wrote: > >>> + /* ?!? What is the point of this adjustment to DST_MASK? */ > >>> + if (code == PLUS || code == MINUS > >>> + || code == MULT || code == ASHIFT) > >>> + dst_mask > >>> + = dst_mask ? ((2ULL << floor_log2 (dst_mask)) - 1) : 0; > >> > >> Yeah, sympathise with the ?!? here :) > > Jeff Law: > >> Inherited. Like the other bit of magic I think I'll do a test with them > >> pulled out to see if I can make something undesirable trigger. > > > > This represents the carry effect. Even if the destination only cares about > > some high order bits, you have to consider all lower order bits of the inputs. > > > > For ASHIFT, you could refine this in the case of a constant shift count. > > Ah, right. Think it would be worth a comment. > > But I wonder whether we should centralise all this code-specific > information into a single place. I.e. rather than having one switch to > say "PLUS is OK" or "AND is OK", and then having code-specific handling > elsewhere, we could enumerate how to handle a code. This carry-back-propagation code is used only in that one place, so I saw no need to put it in a separate function. But if we need to add to it (handle SIGN_EXTEND, maybe handle ASHIFT better) and add lots of comments, it makes sense to put it into an inlinable function so it doesn't disrupt the flow of reading the code. Maybe something like this? /* X, with code CODE, is an operation for which safe_for_live_propagation holds true, and bits set in MASK are live in the result. Compute a make of (potentially) live bits in the non-constant inputs. In case of binop_implies_op2_fully_live (e.g. shifts), the computed mask may exclusively pertain to the first operand. */ HOST_WIDE_INT carry_backpropagate (HOST_WIDE_INT mask, enum rtx_code code, rtx x)