From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by sourceware.org (Postfix) with ESMTPS id C303E3858D32 for ; Fri, 2 Jun 2023 12:45:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C303E3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=free.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=free.fr Received: from [IPV6:2a02:8428:2a4:1a01:e0f2:97fb:4b61:c727] (unknown [IPv6:2a02:8428:2a4:1a01:e0f2:97fb:4b61:c727]) (Authenticated sender: slash.tmp@free.fr) by smtp6-g21.free.fr (Postfix) with ESMTPSA id 3D2CE78032A; Fri, 2 Jun 2023 14:45:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1685709946; bh=5VtkmuAWmx3pcBRi/wHdH9naz5/Yolen70imatOYyJk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vIDkoMqu2tfAcwcI8CGfewXP6EEHm4cX+czUsr4gJDEjgjPFOQe3LOrIY1KJOVzOZ jMPfmJ70qh8GvCxdyZb8r3j24vkATgay5rpk09Lc0X2sKY/B5lSRCl8tTxkc6R4zTp EUuZgb//vnz2fIZybTJW1sgi03mfmA5xckwMEiv+V1ppS+81TO14GQl4mKW0w7Fwy0 ZAgkQsFyHFWphBsgbHqBUPONYofZsdcFjqEqGyOVx3hP6oi6u7yAN5VCjdjAzknvIT jalRoBpevcmulzM8FI9jdzQUaBIVhhsoUouc6+xo4MNK8P7wdmIxY2oPro+7+YjC1h OVigWuLiQDOaw== Message-ID: <37f1a111-4637-b5aa-41c6-5bda26c99422@free.fr> Date: Fri, 2 Jun 2023 14:45:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: Use-case for _addcarryx_u64() wrapper Content-Language: fr, en-US To: gcc-help@gcc.gnu.org, Uros Bizjak Cc: Jakub Jelinek , Jeffrey Walton , Marc Glisse References: From: Mason In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello Uros :) On 01/06/2023 10:40, Uros Bizjak wrote: > On Thu, Jun 1, 2023 at 9:42 AM Mason wrote: > >> As far as I can tell, intrinsics _addcarry_u64() and _addcarryx_u64() are >> plain wrappers around the same __builtin_ia32_addcarryx_u64() function. >> >> https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/adxintrin.h >> >> Thus, I wonder: what is the use-case for the wrappers? >> Why would a programmer not call the builtin directly? >> Is it for compatibility with Intel compilers? > > Builtins are internal implementation detail, it is not published API. > Although rarely, builtins can be changed for some reason or another, > while intrinsic functions from adxintrin.h follow published API. I'm confused. Built-ins are officially documented: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html Using Vector Instructions through Built-in Functions Legacy __sync Built-in Functions for Atomic Memory Access Built-in Functions for Memory Model Aware Atomic Operations Built-in Functions to Perform Arithmetic with Overflow Checking Other Built-in Functions Provided by GCC Built-in Functions Specific to Particular Target Machines What do you mean by "not published API" ? Or perhaps you meant __builtin_ia32_addcarryx_u64 specifically? >> Also, based on the names, I would have assumed that >> _addcarry_u64 generates adc >> while >> _addcarryx_u64 generates adcx/adox ? > > No, they all generate add/adc. Why are there two wrappers for the same function? Is it because the API was not designed by GCC? (Intel ICC intrinsics perhaps?) > There is no use case to maintain two > interleaved carry chains, What do you mean by "there is no use-case" ? Are you saying ADCX/ADOX are useless? Regards