From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id C3D4C3858D1E for ; Mon, 19 Jun 2023 18:32:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C3D4C3858D1E 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-pf1-x433.google.com with SMTP id d2e1a72fcca58-66767d628e2so907357b3a.2 for ; Mon, 19 Jun 2023 11:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687199551; x=1689791551; 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=eD3K4oAD7euLkuP++LVMtOO4vy+FnArs6Sn4tR8stVo=; b=Yuz5knPDsR9ciGVfw2/hjwggqamzSw/lSDiVdKRbo964lL2zpzJj0otUA+CjtrfBEY 38qPUupmddLNfCOiHWsa+g4OK2n49IyofYvfapX9WjvqoJLLR0X5TmvUtNChOSx9Wdyg YT0jyBHooqSfDZk2jLMLGR+CXfZYLoz5mI0S70aBtBVz2Mu8eFS93MLkNXPDSHvgVSBp 0q8zudPQ0pkq1HGCqaZ22sf7Xt9ZKbp9HBy3g/1i6NQPKcpvqUqoKiZZGReFSJ8ldAei 9siagtLDs1IXUBQQLe/cvv8RuTi/016QKp+475q44FdMZzo6w7UZOckJZdAhwyfCTZAO GcWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687199551; x=1689791551; 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=eD3K4oAD7euLkuP++LVMtOO4vy+FnArs6Sn4tR8stVo=; b=ZQN4/iUa+Qk2J/Q7Jzg2OBYD/HXgVPJckTBMC0Q/V0FMVctEvgEF7gHS3EOHgLvB9L 2doiHj8SOMvedEVIyA2MMjXJdfQcQWl+27L29Yh2wYuAhR+zh378zVcXpH/Z0x+2UXHD w51ICOdYbNxqs8baRFzHdh0ptCP4sWQIP58C8qNAmdJ5GXLo6ao+Yd0P5wpwg/KK6BgS O8r1lLSHnZCoorc2EWJPTvISBya2f+NJU+cXWcFLYsPXVTZGcL+XTEq/hg2FtMqTqk3n 2oTlw0YDqD0l5onbD3WeP7y/YW0Q/rqjcTvY4arvcE22oOZ6kBP27wV5T8vmRI9LFNWn woIA== X-Gm-Message-State: AC+VfDyPpQIveLQ/UxOuQwAW9pbPkWa+pWnIUl4E1/GNaS3rYN2116Ks IGbS8SDHB+1f5tT0tqwvjmU= X-Google-Smtp-Source: ACHHUZ6ULzzTGoNRtdSwjeIQ8qUmsqkpCbV1gxvWf9WZzVDD9RWplTm2opZtdlO08FaKO0z8B4BdUw== X-Received: by 2002:a05:6a20:1455:b0:111:2f20:d48f with SMTP id a21-20020a056a20145500b001112f20d48fmr7994659pzi.53.1687199551597; Mon, 19 Jun 2023 11:32:31 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id d17-20020aa78e51000000b0062d859a33d1sm12932pfr.84.2023.06.19.11.32.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jun 2023 11:32:30 -0700 (PDT) Message-ID: Date: Mon, 19 Jun 2023 12:32:28 -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] tree-optimization/110243 - kill off IVOPTs split_offset Content-Language: en-US To: Richard Biener , gcc-patches@gcc.gnu.org Cc: richard.sandiford@arm.com References: <20230616123424.B38AC1330B@imap2.suse-dmz.suse.de> From: Jeff Law In-Reply-To: <20230616123424.B38AC1330B@imap2.suse-dmz.suse.de> 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/16/23 06:34, Richard Biener via Gcc-patches wrote: > IVOPTs has strip_offset which suffers from the same issues regarding > integer overflow that split_constant_offset did but the latter was > fixed quite some time ago. The following implements strip_offset > in terms of split_constant_offset, removing the redundant and > incorrect implementation. > > The implementations are not exactly the same, strip_offset relies > on ptrdiff_tree_p to fend off too large offsets while split_constant_offset > simply assumes those do not happen and truncates them. By > the same means strip_offset also handles POLY_INT_CSTs but > split_constant_offset does not. Massaging the latter to > behave like strip_offset in those cases might be the way to go? > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Comments? > > Thanks, > Richard. > > PR tree-optimization/110243 > * tree-ssa-loop-ivopts.cc (strip_offset_1): Remove. > (strip_offset): Make it a wrapper around split_constant_offset. > > * gcc.dg/torture/pr110243.c: New testcase. Your call -- IMHO you know this code far better than I. jeff