From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 5D0ED3857B95 for ; Fri, 5 Jan 2024 15:01:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5D0ED3857B95 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5D0ED3857B95 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=63.228.1.57 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704466916; cv=none; b=n0sposcrAp/fizl51EwH+O2XykS4pzeJqHl4r13lf5SFCdETtEkDo/QW1MIVTCb5YytD90j4XrmXNJmTVtXsiSNjkBcZ14nL90Pwcdzrn9AxQfRE/cbl6jg+g8kLP0LYxrCaP6rigaOOkJnajMDKIMvYFUmmSehf1P1yzLD3fGw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704466916; c=relaxed/simple; bh=XFqvXEXVakdPSCNGvjexeE4BhQ7sgNFFjweKN3TIB6U=; h=Date:From:To:Subject:Message-ID:Mime-Version; b=pSHnkk9svQxiWwabrEgeSvzYoAaTGkcGDShFlFuWh/mlIxb+ZJe4T56wjYs8yy41GoLHCxJf9lz/h0jfgoKv8SHq7MaQwGAgJo38niduKf9QpjFz7ccbSyk2Ehi3NebxzwKhIH1jKs3Pa+v5RsD7VCIa8oxOeWkTdQToPg6q2cs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 405F0qQ1021943; Fri, 5 Jan 2024 09:00:52 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 405F0q49021938; Fri, 5 Jan 2024 09:00:52 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 5 Jan 2024 09:00:51 -0600 From: Segher Boessenkool To: David Brown Cc: gcc-help@gcc.gnu.org Subject: Re: pragma GCC optimize prevents inlining Message-ID: <20240105150051.GC19790@gate.crashing.org> References: <20240104150325.GA19790@gate.crashing.org> <20240104165517.GB19790@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,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: On Fri, Jan 05, 2024 at 03:24:48PM +0100, David Brown via Gcc-help wrote: > On 04/01/2024 17:55, Segher Boessenkool wrote: > >Most things work on function basis; almost nothing works per RTL > >instruction. There is no per-instruction representation for -fwrapv > >in the RTL stream. > > Yes, I appreciate that. And I can also imagine that carrying such > option information in the AST to make this possible would be a > significant burden, and very rarely of benefit - so unless there is some > other important use-case then it is not a good trade-off. Things like -fwrapv and -ftrapv have semantics that naturally could be done per-insn. Many things are not like that :-/ But even then, what is supposed to happen if some optimisation works on a bunch of insns, some with -fwrapv (or -ftrapv) semantics and some not? The only safe thing to do is to not allow any transformations on mixed insns at all. > >Yes, but that is only true for -ffast-math (which means "the user does > >not care about correct results" anyway). > > (Getting a little off-topic... > > Um, that's not what "-ffast-math" means. It means "the user is using > floating point as a close approximation to real number arithmetic, and > promises to stick to numerically stable calculations". All my uses of > floating point are done with "-ffast-math", and I /do/ care that the > results are correct. But the definition of "correct" for my work is "as > close to the theoretical real number result as you can get with a > limited accuracy format, plus or minus small rounding errors". -ffast-math is allowed to introduce any rounding error it wants. Which can (in a loop for example) easily introduce unlimited rounding error, bigger than the actual result. And this is not just theoretical either. Yes, there is a lot of code where this doesn't matter, in practice. How lucky do you feel today? The only way to safely use -ffast-math is to inspect the generated machine code. After each and every compilation you do. And everyone who uses a different compiler version (or is on a different target, etc.) has to do the same thing. > For other people, full IEEE compliance, support for NaNs, and > bit-perfect repeatable results regardless of optimisations and target > details, are important for correctness. And that's fine, and it's great > that gcc supports both kinds of code - though I believe that > "-ffast-math" would actually be more appropriate for a large proportion > of programs.) Most people think that IEEE 754 was a huge step forward over wild west floating point like we used decades ago. Segher