From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 0C1323858C53 for ; Fri, 10 Nov 2023 09:45:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0C1323858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0C1323858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699609537; cv=none; b=ckSFWFZQhZ/CkYSxmI/pLKllr0Aohy/0HWoB0ihC4HQpJWBXo3rPBBiLuTUZNbvCv/zoiDvZV4DUSbca7MJ/cPwrEYxIOqIgI/Fogjrxqc8lXUuxVNNTabMSqp0Pagvdk0YXXsN8zqJVFG86UPVgwPBLjgHyJ2lGBWcYL9yw0ww= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699609537; c=relaxed/simple; bh=ePMVmn3LysnJLr6MljLfca4LSuraJ4UIswEhvKv9eTE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=qwM2fwQEW9axp1v5nnOFcCUk/1F0b8f4XKMBwCtkz4BdMyOpl9Ogs1ravPBkqyexOKvdkGTyHTXB5I1gMW+7A+vA7xDwg66GQP7WLEzbvA7+JmZ/3xRrTcF8cRT/wrMJy9gEoRhDGqv+tZ82gYZyFhZH6putD5chxJOFSBUfilY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699609535; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TV+3vVIJM7JNUX7+ZojSFv45fMWuRYL0ZSMw9657CsA=; b=O/ZXjRzrcfPINP+oxNigE5/ZvwAaPMRoFXvnfqFt4DW0eQpgc2ak227GxaEAZv74yfX8f2 I+7Ex3RUH4/4GYC1Bbl7dhYIzmLMpwMiZ3fcrJYXp/TQzFwLXnSW00vTfHuwaMLENxAvuX 0Rhk7X4Z6j4Ohr3iT6fQgeltC2rtayo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-677-8v6TbpF4Nh2qlVBxoz3oBA-1; Fri, 10 Nov 2023 04:44:17 -0500 X-MC-Unique: 8v6TbpF4Nh2qlVBxoz3oBA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C6767185A783; Fri, 10 Nov 2023 09:44:16 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.81]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 806981C060AE; Fri, 10 Nov 2023 09:44:16 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 3AA9iDUn1118683 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 10 Nov 2023 10:44:14 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3AA9iCTV1118682; Fri, 10 Nov 2023 10:44:12 +0100 Date: Fri, 10 Nov 2023 10:44:12 +0100 From: Jakub Jelinek To: Richard Biener Cc: "Joseph S. Myers" , Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Add type-generic clz/ctz/clrsb/ffs/parity/popcount builtins [PR111309] Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 Fri, Nov 10, 2023 at 09:19:14AM +0000, Richard Biener wrote: > > Only not promoting the argument will make it directly usable in the > > stdc_leading_zeros, stdc_leading_ones, stdc_trailing_zeros, stdc_trailing_ones, > > stdc_first_leading_zero, ..., stdc_count_zeros, stdc_count_ones, ... > > C23 stdbit.h type-generic macros, otherwise one would need to play with > > _Generic and special-case there unsigned char and unsigned short (which > > normally promote to int), but e.g. unsigned _BitInt(8) doesn't. > > googling doesn't find me stdc_leading_zeros - are those supposed to work > for non-_BitInt types as well and don't promote the argument in that > case? https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf is the C23 draft the C23 wiki points at. E.g. #include unsigned int stdc_leading_zeros_uc(unsigned char value); unsigned int stdc_leading_zeros_us(unsigned short value); unsigned int stdc_leading_zeros_ui(unsigned int value); unsigned int stdc_leading_zeros_ul(unsigned long value); unsigned int stdc_leading_zeros_ull(unsigned long long value); generic_return_type stdc_leading_zeros(generic_value_type value); Returns Returns the number of consecutive 0 bits in value, starting from the most significant bit. The type-generic function (marked by its generic_value_type argument) returns the appropriate value based on the type of the input value, so long as it is a: — standard unsigned integer type, excluding bool; — extended unsigned integer type; — or, bit-precise unsigned integer type whose width matches a standard or extended integer type, excluding bool. The generic_return_type type shall be a suitable large unsigned integer type capable of representing the computed result. My understanding is that because unsigned char and unsigned short are standard unsigned integer types, it ought to support those too, not diagnose them as invalid, and shall return number of consecutive 0 bits in them (which is something different between value for unsigned char and int unless unsigned char has the same precision as int). > If we are spcificially targeting those I wonder why we don't name > the builtins after those? But yes, if promotion is undesirable > for implementing them then I agree. IIRC _BitInt(n) is not subject > to integer promotions. Because the builtins are just something matching in behavior to existing builtins which can be used for those macros, not exact implementation of those. E.g. while #define stdc_leading_zeros(value) \ ((unsigned int) __builtin_clzg (value, __builtin_popcountg ((__typeof (value)) ~(__typeof (value)) 0))) implements (I believe) stdc_leading_zeros above, the second argument to the builtin could be something different needed for other cases, e.g. -1 if one wants to implement ffs-like behavior on unsigned argument, and e.g. stdc_leading_ones would be implemented probably like: #define stdc_leading_ones(value) \ ((unsigned int) __builtin_clzg ((__typeof (value)) ~(value), __builtin_popcountg ((__typeof (value)) ~(__typeof (value)) 0))) Or #define stdc_first_trailing_one(value) \ ((unsigned int) (__builtin_ctzg (value, -1) + 1)) vs. #define stdc_trailing_zeros(value) \ ((unsigned int) __builtin_ctzg (value, __builtin_popcountg ((__typeof (value)) ~(__typeof (value)) 0))) No need to add 14 new type-generic builtins, we can just add the building blocks to implement those. Jakub