From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id CD7703858D35 for ; Thu, 29 Jun 2023 06:24:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD7703858D35 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-x236.google.com with SMTP id 38308e7fff4ca-2b6a0d91e80so4122691fa.3 for ; Wed, 28 Jun 2023 23:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688019856; x=1690611856; 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=7WTejB8eAuOWraYndPdheAGmywS+FnkLa7rNbYUtjc4=; b=TVd2pAx4BBH0k20ZvdUfZLGxa0Tuoi/OHLg6GfWy6lcTfSbqZDLsKfJTUJDAg05Khl 803ioOA+/3fRYpT9ti67uSoLwWiUL+wBqnXWEExstXZQKbH+cZQTVomwwL0OXzC/ge/N uN+7yUtvONUXjiTKFxvyU1/ACxW3gtslPbum3zj63XoQy6YS3ZB5TJs2TVT3loQt1acX NLeTTZuXqk4j6cRerTdDJT5/vxDwPUpimz6b86FpHg/eJuv/He1yAT2ez2vVK6vLaWsl CwbEp5H3nbpcttk6L6ewjus9LQxy84yErli/uAv3spBsHhsjoZbNRnA0sr8mSb+gk8hI f4Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688019856; x=1690611856; 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=7WTejB8eAuOWraYndPdheAGmywS+FnkLa7rNbYUtjc4=; b=EXOpHp7qPNKHo+xS49sTyjkTzzNmHEfqvuPONOtlCNRHWSTMqE/m5PQLF2kUKh94Oo CyJYdgK3D1J0DyipUB1OYIGzKsE/g3gE5yw877pf7/UqGBMqg4mOHOaSAVE+f2RsX8/5 IvUs2ouLpZYPUbdZFBwWXfQQXLdFEiJP84f0ZMHREVBTSIWHQYxBMuNdg/PTEo5InkYk lYdVA8bWOKZPQsyKYcWxq6oYQKVJnMGhtMFgJtrqJ/j0B/jvyH+GtKq0v912K6XCIeY5 EEgwjIwi6ApL26sR9pBUdvKPLI0j6ZKdVcCbchi7IfB/SGnIIagVOPnIlHYz9e81uqst M3MQ== X-Gm-Message-State: AC+VfDxmga3DyO+Q2Luk56XWYl2NdkPmWI17NGKYfGF9VDY6bhj0zN4J 3FMM/ZqCbW0GcfJgrj0BVzNe+OZGZZLmLh3dME7MptCj X-Google-Smtp-Source: ACHHUZ44tj50JmQnEI7jxdcXIy2s+lWwbKgKJqJDiunekakhLMzKPm+jc0/wsaf0g6OCtyMvwYXwZCDib2BbvwPv9Rw= X-Received: by 2002:a2e:8003:0:b0:2b6:a021:7a93 with SMTP id j3-20020a2e8003000000b002b6a0217a93mr8204986ljg.35.1688019855922; Wed, 28 Jun 2023 23:24:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 29 Jun 2023 08:21:08 +0200 Message-ID: Subject: Re: types in GIMPLE IR To: Michael Matz Cc: Krister Walfridsson , gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 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 Wed, Jun 28, 2023 at 5:47=E2=80=AFPM Michael Matz via Gcc wrote: > > Hello, > > On Wed, 28 Jun 2023, Krister Walfridsson via Gcc wrote: > > > Type safety > > ----------- > > Some transformations treat 1-bit types as a synonym of _Bool and mix th= e types > > in expressions, such as: > > > > _2; > > _Bool _3; > > _Bool _4; > > ... > > _4 =3D _2 ^ _3; > > > > and similarly mixing _Bool and enum > > > > enum E:bool { E0, E1 }; > > > > in one operation. > > > > I had expected this to be invalid... What are the type safety rules in = the > > GIMPLE IR? > > Type safety in gimple is defined in terms of type compatiblity, with > _many_ exceptions for specific types of statements. Generally stuff is > verified in verify_gimple_seq., in this case of a binary assign statement > in verify_gimple_assign_binary. As you can see there the normal rules fo= r > bread-and-butter binary assigns is simply that RHS, LHS1 and LHS2 must > all be type-compatible. > > T1 and T2 are compatible if conversions from T1 to T2 are useless and > conversion from T2 to T1 are also useless. (types_compatible_p) The mea= t > for that is all in gimple-expr.cc:useless_type_conversion_p. For this > specific case again we have: > > /* Preserve conversions to/from BOOLEAN_TYPE if types are not > of precision one. */ > if (((TREE_CODE (inner_type) =3D=3D BOOLEAN_TYPE) > !=3D (TREE_CODE (outer_type) =3D=3D BOOLEAN_TYPE)) > && TYPE_PRECISION (outer_type) !=3D 1) > return false; > > So, yes, booleans and 1-bit types can be compatible (under certain other > conditions, see the function). > > > Somewhat related, gcc.c-torture/compile/pr96796.c performs a VIEW_CONVE= RT_EXPR > > from > > > > struct S1 { > > long f3; > > char f4; > > } g_3_4; > > > > to an int > > > > p_51_9 =3D VIEW_CONVERT_EXPR(g_3_4); > > > > That must be wrong? > > VIEW_CONVERT_EXPR is _very_ generous. See > verify_types_in_gimple_reference: Yep. In general these cases should rather use a BIT_FIELD_REF to select a same sized subpart and only then do the rvalue conversion. But as Micha = says below making the IL stricter isn't an easy task. > if (TREE_CODE (expr) =3D=3D VIEW_CONVERT_EXPR) > { > /* For VIEW_CONVERT_EXPRs which are allowed here too, we only c= heck > that their operand is not a register an invariant when > requiring an lvalue (this usually means there is a SRA or IP= A-SRA > bug). Otherwise there is nothing to verify, gross mismatche= s at > most invoke undefined behavior. */ > if (require_lvalue > && (is_gimple_reg (op) || is_gimple_min_invariant (op))) > { > error ("conversion of %qs on the left hand side of %qs", > get_tree_code_name (TREE_CODE (op)), code_name); > debug_generic_stmt (expr); > return true; > } > else if (is_gimple_reg (op) > && TYPE_SIZE (TREE_TYPE (expr)) !=3D TYPE_SIZE (TREE_T= YPE (op))) > { > error ("conversion of register to a different size in %qs", > code_name); > debug_generic_stmt (expr); > return true; > } > } > > Here the operand is not a register (but a global memory object), so > everything goes. > > It should be said that over the years gimples type system became stricter > and stricter, but it started as mostly everything-goes, so making it > stricter is a bumpy road that isn't fully travelled yet, because checking > types often results in testcase regressions :-) > > > Semantics of > > -------------------------------- > > "Wide" Booleans, such as , seems to allow more value= s than > > 0 and 1. For example, I've seen some IR operations like: > > > > _66 =3D _16 ? _Literal () -1 : 0; > > > > But I guess there must be some semantic difference between > > and a 32-bit int, otherwise the wide Boolean type > > would not be needed... So what are the difference? > > See above, normally conversions to booleans that are wider than 1 bit are > _not_ useless (because they require booleanization to true/false). In th= e > above case the not-useless cast is within a COND_EXPR, so it's quite > possible that the gimplifier didn't look hard enough to split this out > into a proper conversion statement. (The verifier doesn't look inside > the expressions of the COND_EXPR, so also doesn't catch this one) Note the above is GIMPLE FE syntax for a constant of a specific type, a regular dump would just show _16 ? -1 : 0; The thing with signed bools is that the two relevant values are -1 (true) and 0 (false), those are used for vector bool components where we also need them to be of wider type (32bits in this case). Richard. > If that turns out to be true and the above still happens when -1 is > replaced by (say) 42, then it might be possible to construct a > wrong-code testcase based on the fact that _66 as boolean should contain > only two observable values (true/false), but could then contain 42. OTOH= , > it might also not be possible to create such testcase, namely when GCC is > internally too conservative in handling wide bools :-) In that case we > probably have a missed optimization somewhere, which when implemented > would enable construction of such wrong-code testcase ;) > > (I'm saying that -1 should be replaced by something else for a wrong-code > testcase, because -1 is special and could justifieably be special-cased i= n > GCC: -1 is the proper arithmetic value for a signed boolean that is > "true"). > > > Ciao, > Michael.