yuvald-sweet-security wrote:
@yonghong-song thank you for taking the time to help with this issue and
providing your suggestions, it’s greatly appreciated. I am also glad to hear
that asm barriers are no longer necessary, as they caused quite some trouble
for me in the past. However, I've enco
yonghong-song wrote:
@yuvald-sweet-security I did one example with your above example,
```
sudo ~/veristat /tmp/test-v1.o --filter=trace_ret_vfs_writev_tail
sudo ~/veristat /tmp/test-v3.o --filter=trace_ret_vfs_writev_tail
```
I can reproduce the issue. The v3 failure reason is actually due to y
yonghong-song wrote:
> > @yuvald-sweet-security Could you share which kernel you are used for above
> > testing?
>
> I ran this on my host machine which is Windows with WSL, kernel
> `6.6.75.1-microsoft-standard-WSL2`. However, I can see similar regressions on
> pretty much every testing VM t
yuvald-sweet-security wrote:
> > Hey,
> > I didn't see this change on the [LLVM 20.1.0 Release
> > Notes](https://releases.llvm.org/20.1.0/docs/ReleaseNotes.html) - it would
> > be nice if you could add those in the future as a heads up.
> > Anyway, I got here after tracing a regression in eBPF
yuvald-sweet-security wrote:
> @yuvald-sweet-security Could you share which kernel you are used for above
> testing?
I ran this on my host machine which is Windows with WSL, kernel
`6.6.75.1-microsoft-standard-WSL2`. However, I can see similar regressions on
pretty much every testing VM that
yonghong-song wrote:
@yuvald-sweet-security Could you share which kernel you are used for above
testing?
https://github.com/llvm/llvm-project/pull/107008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
yuvald-sweet-security wrote:
@4ast perhaps you know who in LLVM can help with adding a "Changes to the BPF
Backend" section to the release notes, similar to how other backends have their
own sections?
https://github.com/llvm/llvm-project/pull/107008
yuvald-sweet-security wrote:
> Thanks @yuvald-sweet-security I am not sure whether I can add default v1->v3
> in llvm20 or not. But let me check anyway.
>
> Also, if the verification failure can be easily reproduced, could you submit
> the test case, we can do some analysis to see why and mayb
yonghong-song wrote:
Thanks @yuvald-sweet-security I am not sure whether I can add default v1->v3 in
llvm20 or not. But let me check anyway.
Also, if the verification failure can be easily reproduced, could you submit
the test case, we can do some analysis to see why and maybe verifier could b
yuvald-sweet-security wrote:
Hey,
I didn't see this change on the [LLVM 20.1.0 Release
Notes](https://releases.llvm.org/20.1.0/docs/ReleaseNotes.html) - it would be
nice if you could add those in the future as a heads up.
Anyway, I got here after tracing a regression introduced in Clang 20 wi
https://github.com/yonghong-song closed
https://github.com/llvm/llvm-project/pull/107008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -38,16 +38,22 @@ void BPFTargetInfo::getTargetDefines(const LangOptions
&Opts,
Builder.defineMacro("__BPF_FEATURE_ADDR_SPACE_CAST");
- if (CPU.empty() || CPU == "generic" || CPU == "v1") {
+ if (CPU == "generic" || CPU == "v1") {
eddyz87 wrote:
Thank
https://github.com/yonghong-song updated
https://github.com/llvm/llvm-project/pull/107008
>From 670fa2f6bf890b34cf256241fccc23d6d1ab3695 Mon Sep 17 00:00:00 2001
From: Yonghong Song
Date: Sat, 31 Aug 2024 11:28:29 -0700
Subject: [PATCH] [BPF] Make -mcpu=v3 as the default
Before llvm20, (void)_
@@ -38,16 +38,22 @@ void BPFTargetInfo::getTargetDefines(const LangOptions
&Opts,
Builder.defineMacro("__BPF_FEATURE_ADDR_SPACE_CAST");
- if (CPU.empty() || CPU == "generic" || CPU == "v1") {
+ if (CPU == "generic" || CPU == "v1") {
yonghong-song wrote:
https://github.com/4ast approved this pull request.
Long overdue. -mcpu=v3 produces much better code and had kernel supports for
many years.
https://github.com/llvm/llvm-project/pull/107008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
https://github.com/eddyz87 approved this pull request.
https://github.com/llvm/llvm-project/pull/107008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -38,16 +38,22 @@ void BPFTargetInfo::getTargetDefines(const LangOptions
&Opts,
Builder.defineMacro("__BPF_FEATURE_ADDR_SPACE_CAST");
- if (CPU.empty() || CPU == "generic" || CPU == "v1") {
+ if (CPU == "generic" || CPU == "v1") {
eddyz87 wrote:
Nitpi
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (yonghong-song)
Changes
Before llvm20, (void)__sync_fetch_and_add(...) always generates locked xadd
insns. In linux kernel upstream discussion [1], it is found that for arm64
architecture, the original semantics of (void)__sync_fetch
llvmbot wrote:
@llvm/pr-subscribers-llvm-binary-utilities
Author: None (yonghong-song)
Changes
Before llvm20, (void)__sync_fetch_and_add(...) always generates locked xadd
insns. In linux kernel upstream discussion [1], it is found that for arm64
architecture, the original semantics of (v
yonghong-song wrote:
cc @anakryiko @jemarch
https://github.com/llvm/llvm-project/pull/107008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/yonghong-song created
https://github.com/llvm/llvm-project/pull/107008
Before llvm20, (void)__sync_fetch_and_add(...) always generates locked xadd
insns. In linux kernel upstream discussion [1], it is found that for arm64
architecture, the original semantics of (void)__sync_
21 matches
Mail list logo
