spavloff wrote:
PR https://github.com/llvm/llvm-project/pull/92146 does not solve the problem
of serialization mentioned above, but it is simple and quick solution for the
reported crash.
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commit
spavloff wrote:
Hi @SLTozer,
Thank you for the report. There is an issue somewhere around the code that
reads/wtites records FP_PRAGMA_OPTIONS and/or FLOAT_CONTROL_PRAGMA_OPTIONS,
which sometimes manifest itseld in broken synchronization of FP options. I will
prepare fix soon.
https://github
SLTozer wrote:
It looks like this is causing crashes when including precompiled headers that
contain optnone functions; this can be reproduced with a very short header file
and any source file, even a completely empty one. Reproducer follows:
```
$ cat header.h
__attribute__((optnone)) void foo
spavloff wrote:
Hi @wjristow,
Thank you for your detailed analysis. Indeed, FPContract looks more like
mandatory option rather than optional optimization. I prepared PR:
https://github.com/llvm/llvm-project/pull/91061, which fixes this issue.
https://github.com/llvm/llvm-project/pull/85605
__
wjristow wrote:
Hi @spavloff.
Given my post above was fairly long, I want to make a short, clarifying
comment. There was a sense in the earlier discussion that there is a problem
in that the spec of `optnone` is imprecise (and that's causing the behavior
difference). A lack of precision of
wjristow wrote:
Hi @spavloff.
Regarding:
> With that goal in mind, having `optnone` and `-O0` be deliberately different
> here makes no sense.
There's no need for them to behave differently here. And in fact, we _want_
them to behave the same. There's a subtle point about FP contraction, in
pogo59 wrote:
> `optnone` is a very strange attribute; it's a directive to the compiler with
> no clear semantics.
In an ideal world, an `optnone` function would be compiled as-if the entire
compilation unit had `-O0`. At `-O0`, Clang attaches `optnone` to every
function, implying that this e
dyung wrote:
> Hi @dyung.
>
> The observed difference is due to the FP contraction turned off if optnone is
> specified. In O0 this optimization is still applied. As a result, the
> function with optnone contains separate fadd and fmul, while without this
> attribute the function contains com
spavloff wrote:
Hi @dyung.
The observed difference is due to the FP contraction turned off if optnone is
specified. In O0 this optimization is still applied. As a result, the function
with optnone contains separate fadd and fmul, while without this attribute the
function contains combined ope
dyung wrote:
Hi, we have an internal test that checks that compiling with and without
optnone at O0 does not change the code generated by the compiler, and one of
the tests we have did change which I bisected back to your change.
The test consists of the following code:
```c++
#include
exter
spavloff wrote:
Thanks!
> Is there any existing bookkeeping we no longer need to do if we're going to
> have this RAII object in scope during function parsing?
It seems handling fast-math is the only case that prevented using this RAII
object.
https://github.com/llvm/llvm-project/pull/85605
https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall approved this pull request.
This seems fine. Is there any existing bookkeeping we no longer need to do if
we're going to have this RAII object in scope during function parsing?
https://github.com/llvm/llvm-project/pull/85605
_
spavloff wrote:
A little about the significance of this fix. To implement pragma FENV_ROUND, we
need to apply the FP options stored in the instance of CompoundStmt to the
builder object, so that it uses the specified rounding mode. It can be done
using the class CGFPOptionsRAII. However in thi
spavloff wrote:
Ping.
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/85605
>From 07e171e0566ab584299a57c210106bb8220c6261 Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 18 Mar 2024 13:20:15 +0700
Subject: [PATCH 1/4] [clang] Set correct FPOptions if attribute 'optnone'
present
github-actions[bot] wrote:
:white_check_mark: With the latest revision this PR passed the Python code
formatter.
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
github-actions[bot] wrote:
:white_check_mark: With the latest revision this PR passed the C/C++ code
formatter.
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/85605
>From 5049e0209e240f0f8a3ccb6e248d55d1480b7bad Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 18 Mar 2024 13:20:15 +0700
Subject: [PATCH 1/4] [clang] Set correct FPOptions if attribute 'optnone'
present
https://github.com/Endilll commented:
`Sema.h` changes look good to me.
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1495,6 +1495,10 @@ Decl *Parser::ParseFunctionDefinition(ParsingDeclarator
&D,
return Actions.ActOnFinishFunctionBody(Res, nullptr, false);
}
+ // Some function attributes (like OptimizeNoneAttr) affect FP options.
+ Sema::FPFeaturesStateRAII SaveFPFeatures(Action
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/85605
>From 5049e0209e240f0f8a3ccb6e248d55d1480b7bad Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 18 Mar 2024 13:20:15 +0700
Subject: [PATCH 1/2] [clang] Set correct FPOptions if attribute 'optnone'
present
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/85605
>From 5049e0209e240f0f8a3ccb6e248d55d1480b7bad Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 18 Mar 2024 13:20:15 +0700
Subject: [PATCH 1/2] [clang] Set correct FPOptions if attribute 'optnone'
present
@@ -2508,6 +2508,10 @@ Decl *Parser::ParseFunctionStatementBody(Decl *Decl,
ParseScope &BodyScope) {
Sema::PragmaStackSentinelRAII
PragmaStackSentinel(Actions, "InternalPragmaState", IsCXXMethod);
+ // Some function attributes (like OptimizeNoneAttr) affect FP options.
https://github.com/rjmccall commented:
Alright. I don't really have a problem with doing this, and this seems like
basically the right approach. You're applying the attributes in the wrong
place, though.
https://github.com/llvm/llvm-project/pull/85605
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/spavloff ready_for_review
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
spavloff wrote:
> optnone is a very strange attribute; it's a directive to the compiler with no
> clear semantics.
`fast-math` also does not have clear semantics. It is however used to express
user's expectations that some assumptions are valid. `optnone` could also be
treated from similar vi
zahiraam wrote:
I have uploaded your patch and compared the attributes generated from your
patch and the little test case from
https://github.com/llvm/llvm-project/issues/62098. The attributes generated
are different. Therefore, the expected optimizations from this patch are going
to be diff
rjmccall wrote:
> > Hmm. Is there some sort of optimization in IRGen that we need to suppress
> > here, or is it something in LLVM code gen? Presumably normal LLVM
> > optimization passes all just skip `optnone` functions.
>
> The issue #62098 demonstrates such case.
Okay. So if I understand
spavloff wrote:
> Hmm. Is there some sort of optimization in IRGen that we need to suppress
> here, or is it something in LLVM code gen? Presumably normal LLVM
> optimization passes all just skip `optnone` functions.
The issue https://github.com/llvm/llvm-project/issues/62098 demonstrates such
https://github.com/spavloff updated
https://github.com/llvm/llvm-project/pull/85605
>From 5049e0209e240f0f8a3ccb6e248d55d1480b7bad Mon Sep 17 00:00:00 2001
From: Serge Pavlov
Date: Mon, 18 Mar 2024 13:20:15 +0700
Subject: [PATCH] [clang] Set correct FPOptions if attribute 'optnone' presents
At
https://github.com/spavloff converted_to_draft
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
Hmm. Is there some sort of optimization in IRGen that we need to suppress
here, or is it something in LLVM code gen? Presumably normal LLVM optimization
passes all just skip `optnone` functions.
Mostly I'm wondering how far we're expected to go with `optnone`.
https://github
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Serge Pavlov (spavloff)
Changes
Attribute `optnone` must turn off all optimizations including fast-math ones.
Actually AST nodes in the 'optnone' function still had fast-math flags. This
change implements fixing FP options before function
https://github.com/spavloff created
https://github.com/llvm/llvm-project/pull/85605
Attribute `optnone` must turn off all optimizations including fast-math ones.
Actually AST nodes in the 'optnone' function still had fast-math flags. This
change implements fixing FP options before function bod
36 matches
Mail list logo
