From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id DD39D3858CD1 for ; Thu, 2 Nov 2023 08:07:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD39D3858CD1 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 DD39D3858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::130 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698912437; cv=none; b=BcHgTQAhsq4hPxBMJG47/o/ylVhhqtHeEbmBHP1OlWKcV6E62rYh4jdJDwtXAJrxxDeOk6S7isE6fGBFn3BVRrZXYrOgmx/ApN43z9pajfG1Thfya7txg0uPh5ZmcbLZoi1PE52nJp9hoDVzFT4mH/P34/GDn9E8+mhR7aeh4rw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698912437; c=relaxed/simple; bh=FPmQiwaqXvAjke+Z7H5DBaH23C9wAu8RMcrLFrtWi+A=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=sPW3HQ+FHDg44WHfDjlDIZZwZC98JIJ0RDvEKA4FlwLRvYqF3b383ZdHZG7lHJyNsejyN6vFwBnGN1pWG/A2sVNacs2y5x+SCfIgCFWVIbR6QPgkrZu2K6dSD+Q40L2u/NZerBQcezZiH7l2nq1D/7p9fRAk3Ka/zE/q1SM/RLo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-5079f9ec8d9so720023e87.0 for ; Thu, 02 Nov 2023 01:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698912434; x=1699517234; 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=rOuEy5wZzpY34el9tO//D5tDZyas66QEPtQu5mD88aM=; b=eYX4OgyuJYZAUVIra7x8wyPNOvB6krsuJPki0lhyeY0BPFXUWNiA03CiZaSB9/JQzg Y6nvUhFApftUyUVctTD/1NnJA+UQ/ec9I4Aor9qU6ML6zndQ+4vyB7caRnUrGfdViQf1 5q0NQmPyU/g+BnEQiEsX6sgf1glxom1dY7NjqUChFtyW8cED94hjKoFYbQUUPWzGUDcm P+UAhcjFscdEzzai7xJA+EIT1UHf9QJFDsvFaCQstUSDxTaVep8Npo5hQjeayPo7lbrv SYCPwOgnKDCXHqogsCXcOT4HGWaIX9J/bC9wBRA4ZW1A0mL4lkqkEkgKV8YqXiRpjEjZ 0eBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698912434; x=1699517234; 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=rOuEy5wZzpY34el9tO//D5tDZyas66QEPtQu5mD88aM=; b=nz1iIRMmVIacwPed4bVqFq6GXVtCFEOtjgwaoeWvnxX2msjQOQCkv6z/m8DJ4JzPwk 1yF9i0qvf0sTqiC+kVp+/UlnIpwL4caummeycCnEhpyPoGrQ32fy+r6AvkM0rghb2zRX RZgBt2+qDZS815Q1PIsLteTdGbxhtj5WjjQoKyMcYmN1La8MAx+7b97WBV9omxBPOxL3 FY2y6/xAgzbh9dzW1ncedtuuylVtLMja3gALt9H1+3ZJicv1OvZybxSDsLOQ8k+pZYNV CW3xF62CEFgjAyyXOmRxCKNnuGNw3nql4Gk6ygS9pez2NkQkuI3RfeWXjjYzJqudcPYY 9LpQ== X-Gm-Message-State: AOJu0Yx3FHrWTMyZs9hBVf0iC1zyPzNM0o/KToqIaIUjsTOiRfgp+IXJ J6K7dkZmyqIOVdIfNW/M/dTaV+rJDCH5fanCT3JZ14WK3Rc= X-Google-Smtp-Source: AGHT+IEMBC+E86WsEOd+CTUDTMb6wNBblu4erGjBmcmh7yojyxCIyihZvOGhtkrmTkf2abwASutt1w2hG+TwIuGjdcA= X-Received: by 2002:a05:6512:1110:b0:504:2345:1b23 with SMTP id l16-20020a056512111000b0050423451b23mr1579619lfg.34.1698912434413; Thu, 02 Nov 2023 01:07:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 2 Nov 2023 09:03:58 +0100 Message-ID: Subject: Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz To: Giuseppe Tagliavini Cc: "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 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, Nov 1, 2023 at 12:30=E2=80=AFPM Giuseppe Tagliavini via Gcc wrote: > > I found an unexpected issue working with an experimental target (availabl= e here: https://github.com/EEESlab/tricore-gcc), but I was able to reproduc= e it on mainstream architectures. For the sake of clarity and reproducibili= ty, I always refer to upstream code in the rest of the discussion. > > Consider this simple test: > > #include > int f(unsigned int a) { > unsigned int res =3D 8*sizeof(unsigned int) - __builtin_clz(a); > if(res>0) printf("test passed\n"); > return res-1; > } > > I tested this code on GCC 9 and GCC 11 branches, obtaining the expected r= esult from GCC 9 and the wrong one from GCC 11. In GCC 11 and newer version= s, the condition check is removed by a gimple-level optimization (I will pr= ovide details later), and the printf is always invoked at the assembly leve= l with no branch. > > According to the GCC manual, __builtin_clz "returns the number of leading= 0-bits in x, starting at the most significant bit position. If x is 0, the= result is undefined." However, it is possible to define a CLZ_DEFINED_VALU= E_AT_ZERO in the architecture backend to specify a defined behavior for thi= s case. For instance, this has been done for SPARC and AARCH64 architecture= s. Compiling my test with SPARC GCC 13.2.0 with the -O3 flag on CompilerExp= lorer I got this assembly: Note the semantic of __builtin_clz is _not_ altered by CLZ_DEFINED_VALUE_AT_ZERO, the behavior of __builtin_clz (x) is that is has undefined result for x =3D=3D 0. CLZ_DEFINED_VALUE_AT_ZERO is only used to optimize code generation when the user writes say x =3D=3D 0 ? 0 : __builtin_clz (x) Richard. > .LC0: > .asciz "test" > f: > save %sp, -96, %sp > call __clzsi2, 0 > mov %i0, %o0 > mov %o0, %i0 > sethi %hi(.LC0), %o0 > call printf, 0 > or %o0, %lo(.LC0), %o0 > mov 31, %g1 > return %i7+8 > sub %g1, %o0, %o0 > > After some investigation, I found this optimization derives from the resu= lts of the value range propagation analysis: https://github.com/gcc-mirror/= gcc/blob/master/gcc/gimple-range-op.cc#L917 > In this code, I do not understand why CLZ_DEFINED_VALUE_AT_ZERO is verifi= ed only if the function call is tagged as internal. A gimple call is tagged= as internal at creation time only when there is no associated function dec= laration (see https://github.com/gcc-mirror/gcc/blob/master/gcc/gimple.cc#L= 371), which is not the case for the builtins. From my point of view, this c= ondition prevents the computation of the correct upper bound for this case,= resulting in a wrong result from the VRP analysis. > > Before considering this behavior as a bug, I prefer to ask the community = to understand if there is any aspect I have missed in my reasoning.