rjmccall wrote:
Okay, it sounds like this is where we've left off:
- The standard is using an odd formulation in
[[class.cdtor]p2](https://eel.is/c++draft/class.cdtor) that we're not sure how
to interpret. It's possible that it's formally slightly weaker than `restrict`
might be, which would m
https://github.com/fhahn commented:
> > I just got a case:
> > ```
> > class A {
> > public:
> >class B {
> >public:
> > B(A *);
> >
> > // some non static data fields
> >};
> > Does this a valid prove that this optimization is not valid ?
>
> This example is fine
guy-david wrote:
> I just got a case:
>
> ```
> class A {
> public:
>class B {
>public:
> B(A *);
>
> // some non static data fields
>};
>
>B b(this);
> };
> ```
>
> Does this a valid prove that this optimization is not valid ?
This example is fine because `
ChuanqiXu9 wrote:
I just got a case:
```
class A {
public:
class B {
public:
B(A *);
// some non static data fields
};
B b(this);
};
```
Does this a valid prove that this optimization is not valid ?
https://github.com/llvm/llvm-project/pull/136792
__
zygoloid wrote:
> @zygoloid Can you explain in your example why `a.n == 2` must be true, when
> your interpretation (which I understood in the same manner) of the standard's
> wording does indicate that the object's state is unspecified?
My reading is that the standard says that the value of `
guy-david wrote:
> > @zygoloid Can you explain in your example why `a.n == 2` must be true, when
> > your interpretation (which I understood in the same manner) of the
> > standard's wording does indicate that the object's state is unspecified?
>
> My reading is that the standard says that the
efriedma-quic wrote:
These days, there's very high demand for "secure" C/C++. From this
perspective, this optimization is a security threat: if you write code that
does an undefined write to "this", you have a lurking security vulnerability
could be exposed with any change to optimization heu
guy-david wrote:
@efriedma-quic ping :)
https://github.com/llvm/llvm-project/pull/136792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/guy-david edited
https://github.com/llvm/llvm-project/pull/136792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/guy-david ready_for_review
https://github.com/llvm/llvm-project/pull/136792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-hlsl
Author: Guy David (guy-david)
Changes
Note: the patch is probably amending the wrong piece of code, I've tried to add
it to `buildThisParam` but hit an assertion because of a missing translation
unit context.
Clang does not transform the followin
guy-david wrote:
Comparison between latest Clang and GCC's output for a snippet out of a
benchmark that could use this optimization: https://godbolt.org/z/35EEvcsPr.
I've ran llvm-test-suite ten times for the before and after, it executed
correctly and expectedly saw no performance gains:
```
zygoloid wrote:
> * I'm not sure this matches the requirements for C++ semantics; noalias is
> very aggressive, so we might end up with undefined behavior in unintended
> cases. I'd like someone familiar with the relevant standard bits to comment
> on the requirements here. CC @zygoloid
The
efriedma-quic wrote:
That said, in terms of whether we actually care about what the committee
says... both the C and C++ committees have a terrible track record on the fine
details of stuff related to memory. I'd be okay with being slightly more
aggressive than the standard technically allows
efriedma-quic wrote:
We don't really specify what, exactly, the consequences are for violating
noalias in LangRef. But... we do say elsewhere "If memory accesses alias even
though they are noalias according to !tbaa metadata, the behavior is
undefined." Probably the same has to apply to noal
guy-david wrote:
Yeah, I realize it's misplaced, I am not familiar with that part of the
project, see the first paragraph in the PR description.
I don't really agree with your second point about breaking people's existing
assumptions on UB :) I am willing to run correctness suites to further v
efriedma-quic wrote:
This isn't really the right place to add this code; we should be doing it
alongside all the other attributes on function definitions...
That said:
- I'm not sure this matches the requirements for C++ semantics; noalias is very
aggressive, so we might end up with undefined
https://github.com/guy-david edited
https://github.com/llvm/llvm-project/pull/136792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff HEAD~1 HEAD --extensions cpp --
clang/lib/CodeGen/CodeGenFunction.cpp
``
https://github.com/guy-david edited
https://github.com/llvm/llvm-project/pull/136792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/guy-david edited
https://github.com/llvm/llvm-project/pull/136792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/guy-david edited
https://github.com/llvm/llvm-project/pull/136792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/guy-david created
https://github.com/llvm/llvm-project/pull/136792
Note: the patch is probably amending the wrong piece of code, I've tried to add
it to `buildThisParam` but hit an assertion because of a missing translation
unit context.
Clang, unlike GCC, does not transfor
23 matches
Mail list logo
