From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id BBFBC3858409 for ; Fri, 3 Feb 2023 11:35:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BBFBC3858409 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-lj1-x22a.google.com with SMTP id b13so4933497ljf.8 for ; Fri, 03 Feb 2023 03:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fbha2OG8/k0if4eXH2KThslKHPzCFRhONu4t3j6ckag=; b=fq/WqQyMREySLAD1P41siSSNnaJa1oDhFMzEMO0jyI8tn1l7F/+fA+8JkRiid2wmCI RA+yX1+OaUzYNI5HknVKQixOhwzrfJA9Ya4vLQG8vbHfWsuxQkJ1qZjwmLWku+ipKKLo c41/JT/j1cOC4CylORCYi3zybRKUKwc3Eq+sPXR7LJtj+4IBbxMH8DHfMzViaErxmRP7 TKBOpcEIUjtlRSZVK/eOlfC0mFzaG4uU70lBJB8CGDFMD54f1gXGqv68xZ+XAtKRNJnk zUi2PmgKmFdw0q4BheIH7g6ZPnLXeEKulq9/tLrgTVnl05WtZ3GDJDR1T5p9jCn/iwZi vw9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=fbha2OG8/k0if4eXH2KThslKHPzCFRhONu4t3j6ckag=; b=sgdE6qhqqz5mS5tIygw5XdAEtBGkcDMTHkwgAAUZ8ZloL5RtDZX5t0vcscMy8f2Bpy 2IafhIsGqrA+YfT7OzP4U3iv/hDUZgfjStva6TJVGSDgd1jjLXtyWWTc1IUG6zU2aRAC eDiJXNUuM1pCO4N5Nlh3G4rK5rXxMiN9n2L60DklavCz4KHC0H7naaVNzKL43/NISqC8 Ebqzh9OeQm9GqprtlGD3yxuckuXqg0XSLH8/66dAO9FG596RwwCGvDdUTOviY4yb3/pm cvFS/KHZ+gRRPeq6toBvWdCY0/0k8lFse7WKo5ed/H+m8uLxzL88IowOiy2WTNe36ti/ awGQ== X-Gm-Message-State: AO0yUKWRHR/ketY0Tki1Cy78J4j+Bc4InWW1ygOxnxdbPfi/9rRIMOHw OuwRB7xubr48+Su5yQOSSkIdt9ep90wmNAhNbys= X-Google-Smtp-Source: AK7set8jfLxH3Z/9KY4wARFF4VILHm3AkXWLim+NhHSTKGDfnhscNKCQYbo+ooiDwamGAimUIlaMxdav1xZb88WhIUY= X-Received: by 2002:a2e:2c0e:0:b0:28b:77fd:d92b with SMTP id s14-20020a2e2c0e000000b0028b77fdd92bmr1483794ljs.86.1675424145040; Fri, 03 Feb 2023 03:35:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 3 Feb 2023 12:35:32 +0100 Message-ID: Subject: Re: [PATCH] ipa: Avoid invalid gimple when IPA-CP and IPA-SRA disagree on types (108384) To: Martin Jambor Cc: GCC Patches , Jan Hubicka Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 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 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 Fri, Feb 3, 2023 at 10:40 AM Martin Jambor wrote: > > On Fri, Feb 03 2023, Richard Biener wrote: > > On Thu, Feb 2, 2023 at 5:20 PM Martin Jambor wrote: > >> > >> Hi, > >> > >> when the compiled program contains type mismatches between callers and > >> callees when it comes to a parameter, IPA-CP can try to propagate one > >> constant from callers while IPA-SRA may try to split a parameter > >> expecting a value of a different size on the same offset. This then > >> currently leads to creation of a VIEW_CONVERT_EXPR with mismatching > >> type sizes of LHS and RHS which is correctly flagged by the GIMPLE > >> verifier as invalid. > >> > >> It seems that the best course of action is to try and avoid the > >> situation altogether and so this patch adds a check to IPA-SRA that > >> peeks into the result of IPA-CP and when it sees a value on the same > >> offset but with a mismatching size, it just decides to leave that > >> particular parameter be. > >> > >> Bootstrapped and tested on x86_64-linux, OK for master? > > > > OK. I suppose there are guards elsewhere that never lets a > > non-UHWI size type (like variable size or poly-int-size) through > > any of the SRA or CP lattices? > > SRA tracks its accesses in simple integers so yes for that part. > > As far IPA-CP is concerned... all the values tracked conform to > is_gimple_ip_invariant, so are either ADDR_EXPRs of a global variable or > is_gimple_constant's. So its size should never be variable and I hope > also never a complex poly-int. If you think it would be better, I can > of course add the check. I think it's OK as-is given this explanation. Richard. > Thanks, > > Martin > > > >> gcc/ChangeLog: > >> > >> 2023-02-02 Martin Jambor > >> > >> PR ipa/108384 > >> * ipa-sra.cc (push_param_adjustments_for_index): Remove a size check > >> when comparing to an IPA-CP value. > >> (dump_list_of_param_indices): New function. > >> (adjust_parameter_descriptions): Check for mismatching IPA-CP values. > >> Dump removed candidates using dump_list_of_param_indices. > >> * ipa-param-manipulation.cc > >> (ipa_param_body_adjustments::modify_expression): Add assert checking > >> sizes of a VIEW_CONVERT_EXPR will match. > >> (ipa_param_body_adjustments::modify_assignment): Likewise. > >> > >> gcc/testsuite/ChangeLog: > >> > >> 2023-02-02 Martin Jambor > >> > >> PR ipa/108384 > >> * gcc.dg/ipa/pr108384.c: New test. > >> ---