From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by sourceware.org (Postfix) with ESMTPS id E56AC38582AF for ; Mon, 11 Mar 2024 07:46:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E56AC38582AF Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E56AC38582AF Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::136 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710143183; cv=none; b=r7HqqBSmlcztc05HMDZcz/apl5WAvzWcbnBH62gKZg1xrHZJZtq6CV6TNEG0wJ45p0v7UUjTGe9SzLH0drhe8ZOwtJ3DtPdVUuO5X/pMetr0/r+oW+9e1ix5vwDRX6dlurC1nce5TV7c2GmjqjrZOmrggfAlOxj/hycapOVveFc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710143183; c=relaxed/simple; bh=M3iUP0g9V/2W3yOk0C/4m0fp9Y4D0UzM3hD/wKkTiug=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=kFPIUQn0gl2iZrgRkR85bgcTS0iBxLO4SguJkmLxS8KoBZUZKA/NDWpPdR93+hKYxOWC+iiNPlowN+TZtebLJ1otboo2b7wlqUgi44bCzGwWj3LPGIaYdUVgDcUXDYTbJDePyRH/0yjCTTjrdQqF8RzDD25xLBlGR3czh+dJxbA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5131316693cso5402987e87.0 for ; Mon, 11 Mar 2024 00:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710143180; x=1710747980; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=f8VE4HXimwx0nlL1oKn7nHsxgBPMSZydzMaYSYiTr6A=; b=MPC6QCbjIkcYybsLNg3+sQFjP6MP94vnoYxocVIhrIE4NsB0PcoDb0bzGKTdGarq1Z 1LnyZhgLciL40xoKK1AhONsHMsdCU6/peuEIhFxVg9zDLrqiADNTaMxi409XzwlFL5Tq JCT0d9/I9AlOkyvPbsmwffnHjf6AB3lCDpLyl0o+U3itUSaL+gpyGkpgonruXS0zgZHK 8MBgLF4+Ypu0zKn1NOx4h74f9p5EeOVZnBHscyh05jnOdJG3OjtC8jBXtMrJ1SPqWod4 HJNY/gV9c4cAL6fVkYMfyS1wsgqQHJgDy6ckpE9xIiiIs60epDsvi2kpRtx8vW2ds3ma oyxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710143180; x=1710747980; h=content-transfer-encoding:cc: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=f8VE4HXimwx0nlL1oKn7nHsxgBPMSZydzMaYSYiTr6A=; b=pwvzs6pfNoDPbstRjDoajF+XMkrcVqmpbi9JfL8ZaaRZdbQk9cmpAPPbxCV1FvxoNP 0/pDHKwqZLmABg+0Q1gBNPFtzoeoFIdq7VW0PPAS/32Wkl/KoHu+vwpCkC070oIXFzqH WZS1rz1In56roTgAyCjkb2pYvsP/1liy29D2DLwT84KHZRoZqrCxg8kSdlC3cCOcfo+U 6YyFAohJywmH20+hLWvAr1OW6Mhg7vU3E0YIWfCQFVLcRsuKrlVFdJ+YR5rX/Eg3khcG wD+ZbsfZrWVh2N9kMehDRehN0F6kPQ6Chf/tNevJGYvWT77/8oioSd0qS3JjHzGn6p+8 3ccQ== X-Forwarded-Encrypted: i=1; AJvYcCWRHo+nIyfZGzHK1arpHTABizGAJKgzVgxmlpdgiAl2iGfFzHMzi2NAj3CJEw1YIObZp0btIYXyG5n3wYZuUDKsj827LjmJ5A== X-Gm-Message-State: AOJu0YzUm/oh+e8PGS6TbTlI4S31RC8RndCbKt8wCoOLPDqMkjKhV6s6 Kt0jCdmei24KpHB9kQszNwBRhZd67Dg2nz45UfQwgVMsdZwIh0d/ChCvHC694NqcuCQWo3yP6+P NPi9FXJPPuKlOuPDI8kOyDtGVZCM= X-Google-Smtp-Source: AGHT+IHBQb/BGCLWBu1NkKlipgUP+ELedXNZQOAARUOnYm8ALQ079VartsmcL9+oY8hio1Bon+N7wtDvoYU+ySXK0Sk= X-Received: by 2002:ac2:5151:0:b0:513:64c5:105b with SMTP id q17-20020ac25151000000b0051364c5105bmr3876111lfd.27.1710143179867; Mon, 11 Mar 2024 00:46:19 -0700 (PDT) MIME-Version: 1.0 References: <4fb49d29-3688-4c14-991f-196ca086d479@ventanamicro.com> <61bfe66a-6e08-4ca9-9f0a-81082762e702@ventanamicro.com> In-Reply-To: <61bfe66a-6e08-4ca9-9f0a-81082762e702@ventanamicro.com> From: Richard Biener Date: Mon, 11 Mar 2024 08:46:08 +0100 Message-ID: Subject: Re: [RFC] [PR tree-optimization/92539] Optimize away tests against invalid pointers To: Jeff Law Cc: Andrew Pinski , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 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,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 Sun, Mar 10, 2024 at 10:09=E2=80=AFPM Jeff Law w= rote: > > > > On 3/10/24 3:05 PM, Andrew Pinski wrote: > > On Sun, Mar 10, 2024 at 2:04=E2=80=AFPM Jeff Law wrote: > >> > >> Here's a potential approach to fixing PR92539, a P2 -Warray-bounds fal= se > >> positive triggered by loop unrolling. > >> > >> As I speculated a couple years ago, we could eliminate the comparisons > >> against bogus pointers. Consider: > >> > >>> [local count: 30530247]: > >>> if (last_12 !=3D &MEM [(void *)"aa" + 3B]) > >>> goto ; [54.59%] > >>> else > >>> goto ; [45.41%] > >> > >> > >> That's a valid comparison as ISO allows us to generate, but not > >> dereference, a pointer one element past the end of the object. > >> > >> But +4B is a bogus pointer. So given an EQ comparison against that > >> pointer we could always return false and for NE always return true. > >> > >> VRP and DOM seem to be the most natural choices for this kind of > >> optimization on the surface. However DOM is actually not viable becau= se > >> the out-of-bounds pointer warning pass is run at the end of VRP. So > >> we've got to take care of this prior to the end of VRP. > >> > >> > >> > >> I haven't done a bootstrap or regression test with this. But if it > >> looks reasonable I can certainly push on it further. I have confirmed = it > >> does eliminate the tests and shuts up the bogus warning. > >> > >> The downside is this would also shut up valid warnings if user code di= d > >> this kind of test. > >> > >> Comments/Suggestions? > > > > ENOPATCH > Yea, realized it as I pushed the send button. Then t-bird crashed, > repeatedly. > > Attached this time.. There's fold-const.cc:address_compare and tree-ssa-alias.cc:ptrs_compare_unequal, both eventually used by match.pd that could see this change, the former alr= eady special-cases STRING_CST to some extent. I'll note that the value we simplify such comparison to is arbitrary. Doing such simplification directly (as opposed to only benefit from its undefinedness indirectly) always gives me the creeps ;) IMO we should instead simplify the condition to __builtin_unreachable/trap = aka isolate the path as unreachable. Richard. > jeff >