From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by sourceware.org (Postfix) with ESMTPS id AD6BD3858D35 for ; Mon, 27 Jul 2020 10:29:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AD6BD3858D35 Received: by mail-ej1-x644.google.com with SMTP id l4so16452759ejd.13 for ; Mon, 27 Jul 2020 03:29:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ACM4gF6niV722MPlCehowt1lJkv7ZjIP9JVIy3KnV1A=; b=F86mtHXNl7xjGySpLwz0KcBiibsv6mpoeo+ibj63ztujIgnhi93uM9I+p669tyLFX7 Dscg1X78EiXTmtWaiuz8sajFqlGw5bRhgDB6MHAtfcmxapXYneVaLkd8cV7cd4/S1iMn iLPiB9z74grdHe1xRYjPFWcQF/qVB8uKDsNAGAZTkvkY+wgaxBfMAiBpMyOrZeE1sV7s 6uPoaebW+VataxnnCzWhTlomKiTh8CeP42gj80cAunVCBHrCKlCJo69hMUdoTRgCiV9w XWJkBT1x2pHmRjY7k9id5JmaKwLIICFr8jUzIZsQEEOwErtNbPzIwDwjbUUP/9ZBYiwM lTAQ== X-Gm-Message-State: AOAM531/K+L5Q9F0w6pnK62FuamHSBShjzBE5oWZUzkTd5DUbjVzkZkC EOap59i9rFHqhKiXT47I5x51XQNOsznkD/Alr/g= X-Google-Smtp-Source: ABdhPJze9q2Q9FoMuS3KvFg8ln/9CdKujzWYfRq1fTXfc3/Yrmn4ouSfsWgtFUi/BU88unj/cM59OTDqC9NDP/q+32E= X-Received: by 2002:a17:906:2cc2:: with SMTP id r2mr8632072ejr.482.1595845762772; Mon, 27 Jul 2020 03:29:22 -0700 (PDT) MIME-Version: 1.0 References: <20200722151450.1540130-1-stefansf@linux.ibm.com> In-Reply-To: From: Richard Biener Date: Mon, 27 Jul 2020 12:29:11 +0200 Message-ID: Subject: Re: [PATCH] [RFC] vect: Fix infinite loop while determining peeling amount To: Richard Biener , Richard Biener via Gcc-patches , Stefan Schulze Frielinghaus , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:29:25 -0000 On Mon, Jul 27, 2020 at 11:45 AM Richard Sandiford wrote: > > Richard Biener writes: > > On Mon, Jul 27, 2020 at 11:09 AM Richard Sandiford > > wrote: > >> > >> Richard Biener via Gcc-patches writes: > >> > On Wed, Jul 22, 2020 at 5:18 PM Stefan Schulze Frielinghaus via > >> > Gcc-patches wrote: > >> >> > >> >> This is a follow up to commit 5c9669a0e6c respectively discussion > >> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549132.html > >> >> > >> >> In case that an alignment constraint is less than the size of a > >> >> corresponding scalar type, ensure that we advance at least by one > >> >> iteration. For example, on s390x we have for a long double an alignment > >> >> constraint of 8 bytes whereas the size is 16 bytes. Therefore, > >> >> TARGET_ALIGN / DR_SIZE equals zero resulting in an infinite loop which > >> >> can be reproduced by the following MWE: > >> > > >> > But we guard this case with vector_alignment_reachable_p, so we shouldn't > >> > have ended up here and the patch looks bogus. > >> > >> The above sounds like it ought to count as reachable alignment though. > >> If a type requires a lower alignment than its size, then that's even > >> more easily reachable than a type that requires the same alignment as > >> the size. I guess at one extreme, a target alignment of 1 is always > >> reachable. > > > > Well, if the element alignment is 8 but its size is 16 then when presumably > > the desired vector alignment is a multiple of 16 we can never reach it. > > Isn't this the case here? > > If the desired vector alignment (TARGET_ALIGN) is a multiple of 16 then > TARGET_ALIGN / DR_SIZE will be nonzero and the problem the patch is > fixing wouldn't occur. I agree that we might never be able to reach > that alignment if the pointer starts out misaligned by 8 bytes. > > But I think that's why it makes sense for the target to only ask > for 8-byte alignment for vectors too, if it can cope with it. 8-byte > alignment should always be achievable if the scalars are ABI-aligned. > And if the target does ask for only 8-byte alignment, TARGET_ALIGN / > DR_SIZE would be zero and the loop would never progress, which is the > problem that the patch is fixing. > > It would even make sense for the target to ask for 1-byte alignment, > if the target doesn't care about alignment at all. Hmm, OK. Guess I still think we should detect this somewhere upward and avoid this peeling compute at all. Somehow. Richard. > Thanks, > Richard