From patchwork Sun May 19 16:16:15 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Glisse X-Patchwork-Id: 1101579 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-501105-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="gq1lAIE0"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 456Rx54RbXz9s5c for ; Mon, 20 May 2019 02:16:39 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=xG1tgNfFkYb6aytHAOshf1XAWo13vTU1kFUYf4D5MyXmz6K8sM73k drAUGF4lnoWO3b/SPHLr1GOhbHlWB/i7tySoTbZmYz5joqhBILhCQaLVHb/sCyVS ASay0uN+41O64XGHDcLHcpiTA0jRqe/EYMpyw753GIOxU3tqa47MnE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=p8de4kYi9n8QDHXLtHv8mXtuM/k=; b=gq1lAIE0OKQwLLJaM+Bc YOjewkVsfavxyMlLr3IFONpfqLvphOUpazNtPsMsIn5ic0z5MmJa0jFY9VthlgoK 2l1tAxlDgQa9Y/0Zi/ODBcDjI5CYh4F297w3SBiqfpEaKOxMosu0fzLradVFxELY mrBoYyhnTYzZoqyPyAL5jVU= Received: (qmail 120399 invoked by alias); 19 May 2019 16:16:33 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 120391 invoked by uid 89); 19 May 2019 16:16:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, SPF_PASS autolearn=ham version=3.3.1 spammy=to_wide, comparisons, build_zero_cst, D*2 X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 19 May 2019 16:16:30 +0000 Received: from grove.saclay.inria.fr ([193.55.177.244]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2019 18:16:19 +0200 Date: Sun, 19 May 2019 18:16:15 +0200 (CEST) From: Marc Glisse To: gcc-patches@gcc.gnu.org Subject: Simplify more EXACT_DIV_EXPR comparisons Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Hello, 2 pieces: - the first one handles the case where the denominator is negative. It doesn't happen often with exact_div, so I don't handle it everywhere, but this one looked trivial - handle the case where a pointer difference is cast to an unsigned type before being compared to a constant (I hit this in std::vector). With some range info we could probably handle some non-constant cases as well... The second piece breaks Walloca-13.c (-Walloca-larger-than=100 -O2) void f (void*); void g (int *p, int *q) { __SIZE_TYPE__ n = (__SIZE_TYPE__)(p - q); if (n < 100) f (__builtin_alloca (n)); } At the time of walloca2, we have _1 = p_5(D) - q_6(D); # RANGE [-2305843009213693952, 2305843009213693951] _2 = _1 /[ex] 4; # RANGE ~[2305843009213693952, 16140901064495857663] n_7 = (long unsigned intD.10) _2; _11 = (long unsigned intD.10) _1; if (_11 <= 396) [...] _3 = allocaD.1059 (n_7); and warn. However, DOM3 later produces _1 = p_5(D) - q_6(D); _11 = (long unsigned intD.10) _1; if (_11 <= 396) [...] # RANGE [0, 99] NONZERO 127 _2 = _1 /[ex] 4; # RANGE [0, 99] NONZERO 127 n_7 = (long unsigned intD.10) _2; _3 = allocaD.1059 (n_7); so I am tempted to say that the walloca2 pass is too early, xfail the testcase and file an issue... A single_use restriction would also probably fix this testcase, but I don't think that's a good idea, the new code is better because the division is now in the branch. 2019-05-20 Marc Glisse gcc/ * match.pd (X/[ex]D= 5; +} + +/* { dg-final { scan-tree-dump-not "exact_div_expr" "optimized" } } */ Index: gcc/testsuite/gcc.dg/tree-ssa/cmpexactdiv-4.c =================================================================== --- gcc/testsuite/gcc.dg/tree-ssa/cmpexactdiv-4.c (nonexistent) +++ gcc/testsuite/gcc.dg/tree-ssa/cmpexactdiv-4.c (working copy) @@ -0,0 +1,10 @@ +/* { dg-do compile } */ +/* { dg-options "-O -fdump-tree-optimized-raw" } */ + +int f(int*a,int*b,int*c){ + __PTRDIFF_TYPE__ x = -(b - a); + __PTRDIFF_TYPE__ y = -(c - a); + return x < y; +} + +/* { dg-final { scan-tree-dump-not "exact_div_expr" "optimized" } } */