From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 523CA3886C74 for ; Sat, 1 Jun 2024 17:30:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 523CA3886C74 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 523CA3886C74 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::630 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717263016; cv=none; b=GhVY2L/Uke4s2ZQcQg7CKOXZ008aFqxCpLPvniJ/J2SyPL2eK7coJDaO9JcGFpmsqHWp/1F+iF1jTMOJ3EclezwqVFJa6UnFa8bFnKLfQuR1bWnDYi4CPbwfFjrGr4dclba1N5QFeI4CHUDucxRsHB1/GsIz2TUaKYFceHmzG4k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717263016; c=relaxed/simple; bh=FfQKrcwrP4aLHoc6J/60M/fGHaRdnRF85yT3y5LhYss=; h=DKIM-Signature:From:Mime-Version:Subject:Date:Message-Id:To; b=dcm36EcT3xVb8a1vskjbkYkRmiXWjD3VoJDKow2fTb0Fk42iB3DZd0G/Zqu1twhb82GFuXYXwsSbm5M4uG2Cwk5crdjhq2ehIRfro6BqOSH6oge8o4OYqKVJpr6FZEivC/HgzU9OlC1GOWOIGdh83jwis21qfFTXSqojkBVyAwk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a635a74e031so391178866b.0 for ; Sat, 01 Jun 2024 10:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717263013; x=1717867813; darn=gcc.gnu.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=EDXPDY6FNB4qBxGjpCs1JXVBGoG8ptkZnLTcZ2kFxlQ=; b=HicNtKPCSDR6b7be7UBd3UU9hiu7NWIL+gI6PcYrGhteVM9dKtJHpNAE7tZpZQ1plE hSjn1PkMxYqzil/RlVkCv1oDHZLrTJxDB8MaeFxSzBGv33xn387iysVkw19mtsQERSza AzWrdl7UpKVaqMCNVCw6+g40cu30HYdtsm6u8+g4DcvjZWG5rL3+m5VCg1uKhjSD1VOo 7bVtHvOm5yi94MYmfSeeAsAHjJfZggg5h5h42oQyy+mbL0mH6SUS7a/qAcYq44waO0js t/JDfpHuGrNL4N/nbsHfLqa3w9qorjLCUi98Q0K1VsAHDTNPbnLGC1vE+rtHaBnDn83V AWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717263013; x=1717867813; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EDXPDY6FNB4qBxGjpCs1JXVBGoG8ptkZnLTcZ2kFxlQ=; b=YiN64P8VXUh1F0Ahhc0UVhEVfBhb0CW0BV0CojmHXDnzW+QqWgoFj9bYpCyW93ANGt 2foXjh7CKTHYZTfauAS3isyVN4313Pu11GMujdchesiy4HFIbN5YgNrkwb0bMckUNdgH L6evjiU4MF7bpX5pQOurzT14n1U4WIJaH/v13KHAZu8jIs3MF54Lg3k2/w1sUnNpIlSa Ah7x719WVsKwO5BcZTAMORTX8gtip21qUDDy0LrM7qsZvquJDvpZUl1x1tAlvgMpt61K 8AvxyAwH7DON2M+pZih1zTrcokW2lNt4FVIsFjDHYLN5SWzcSCFfY1OZ9y+DxGteLT0L dA/w== X-Forwarded-Encrypted: i=1; AJvYcCV9HPaFZdgInhI5Tx/qzl/bfXdldhlHRoA4EH+vVuhh5lWspaizDyqGY0MrP0we4Pg/Gm5vt35pJEHYc+t397k= X-Gm-Message-State: AOJu0Yya3WOoowj6Du/ZolUvBJgr1utT+Vu8nINgiS2xtYQvZf3u+qpX 3pZOoHYccg9sHs1VDSgx64lf1wD81cQrmXGpiX+nRVlZnZc1y2eO X-Google-Smtp-Source: AGHT+IGqjECJWjD4PWO+PbZVZqWn5vvzE8MpUKT+y16by93by3iiYobPdorBgLmSaf51rPsCqbLPng== X-Received: by 2002:a17:906:ecb6:b0:a68:2d37:fb5a with SMTP id a640c23a62f3a-a682d37fd6amr354011366b.4.1717263012413; Sat, 01 Jun 2024 10:30:12 -0700 (PDT) Received: from smtpclient.apple (dynamic-077-004-081-025.77.4.pool.telefonica.de. [77.4.81.25]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a67ea67b4b2sm220309766b.117.2024.06.01.10.30.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Jun 2024 10:30:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: How to avoid some built-in expansions in gcc? Date: Sat, 1 Jun 2024 19:30:01 +0200 Message-Id: References: Cc: Paul Koning , gcc@gcc.gnu.org In-Reply-To: To: Georg-Johann Lay X-Mailer: iPhone Mail (21F90) X-Spam-Status: No, score=-3.0 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: > Am 01.06.2024 um 17:41 schrieb Georg-Johann Lay : >=20 > =EF=BB=BF >=20 > Am 31.05.24 um 22:12 schrieb Richard Biener: >>>> Am 31.05.2024 um 20:56 schrieb Georg-Johann Lay : >>>=20 >>> =EF=BB=BF >>>=20 >>> Am 31.05.24 um 19:32 schrieb Richard Biener: >>>>>> Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc := >>>>>=20 >>>>> =EF=BB=BF >>>>>=20 >>>>>> On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Am 31.05.24 um 17:00 schrieb Paul Koning: >>>>>>>>> On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote= : >>>>>>>>>=20 >>>>>>>>> What's the recommended way to stop built-in expansions in gcc? >>>>>>>>>=20 >>>>>>>>> For example, avr-gcc expands isinff() to a bloated version of an i= sinff() implementation that's written in asm (PR115307). >>>>>>>>>=20 >>>>>>>>> Johann >>>>>>> Isn't that up to the target back end? >>>>>>> paul >>>>>>=20 >>>>>>=20 >>>>>> Yes, that's the reason why it's a target PR. >>>>>>=20 >>>>>> My question is where/how to do it. >>>>>>=20 >>>>>> It's clear that twiddling the options works and is a simple and compr= ehensible solution, but it seems a bit of a hack to me. >>>>>>=20 >>>>>> Johann >>>>>=20 >>>>> I haven't dug deep into this, but I would think at least part of the a= nswer is in the target cost functions. If those assign RTX cost according t= o size, then the result would be the optimizer would favor smaller code. Ri= ght? >>>>>=20 >>>>> Does inline assembly expansion of builtins depend on target code suppl= ying that expansion? If so, the answer would be not to supply it, or at lea= st not unless asked for by an option. If it comes from common code, that's a= different matter, then perhaps there should be target hooks to let the targ= et disallow or discourage such expansion. I might want such a thing for pdp= 11 as well. >>>> The function in question is folded to a comparison very early if the ta= rget does not implement an optab for it. After that everything is lost. A w= orkaround is to define an optab but let expansion always FAIL. >>>> Richard >>>=20 >>> You have a pointer how to define a target optab? I looked into optabs co= de but found no appropriate hook. For isinf is seems is is enough to p= rovide a failing expander, but other functions like isnan don't have an opta= b entry, so there is a hook mechanism to extend optabs? >> Just add corresponding optabs for the missing cases (some additions are p= ending, like isnornal). There=E2=80=99s no hook to prevent folding to FP co= mpares nor is that guarded by other means (like availability of native FP op= s). Changing the guards would be another reasonable option. >> Richard >=20 > There are many other such folds, e.g. for isdigit(). The AVR libraries ha= ve all this in hand-optimized assembly, and all these built-in expansions ar= e bypassing that. Open-coded C will never beat that assemlbly code, at leas= t not with the current GCC capabilities. The idea is that isdigit() || isalpha() or similar optimize without special c= asing the builtins. > How would I go about disabling / bypassing non-const folds from ctype.h an= d the many others? I think this mostly shows we lack late recognition of open-coded isdigit and= friends, at least for the targets where inlining them is not profitable. A pragmatic solution might be a new target hook, indicating a specified buil= tin is not to be folded into an open-coded form. A good solution would base this on (size) costs, the perfect solution would r= e-discover the builtins late and undo inlining that didn=E2=80=99t turn out t= o enable further simplification. How is inlined isdigit bad on AVR? Is a call really that cheap considering p= ossible register spilling around it? Richard=20 >=20 > Johann