[COMMITTED BPF] bpf: fix printing of memory operands in pseudoc asm dialect

The BPF backend was emitting memory operands in pseudo-C syntax without surrounding parentheses. These were being provided in the corresponding instruction templates. This was causing GCC emitting invalid instructions when finding inline assembly with memory operands like: asm volatile

Re: [PATCH] bpf: set PREFERRED_DEBUGGING_TYPE to BTF_DEBUG

Hi David. OK. Thanks for the patch. > BTF is the standard debug info used with BPF programs, so it makes sense > to default to BTF rather than DWARF. > > Tested on x86_64-linux-gnu host for bpf-unknown-none target. > > gcc/ > * config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to

Re: [PATCH] bpf: avoid issues with CO-RE and -gtoggle

Hi Faust. OK. Thanks for the patch. > Compiling a BPF program with CO-RE relocations (and BTF) while also > passing -gtoggle led to an inconsistent state where CO-RE support was > enabled but BTF would not be generated, and this was not caught by the > existing option parsing. This led to an

[COMMITTED BPF] bpf: default to using pseudo-C assembly syntax by default

At this point the kernel headers that almost all BPF programs use contain pseudo-C inline assembly and having the GNU toolchain using the conventional assembly syntax by default would force users to specify the command-line option explicitly almost all of the time, which is very inconvenient.

[COMMITTED BPF] bpf: define BPF feature pre-processor macros

This commit makes the BPF backend to define the following macros for c-family languages: __BPF_CPU_VERSION__ This is a numeric value identifying the version of the BPF "cpu" for which GCC is generating code. __BPF_FEATURE_ALU32 __BPF_FEATURE_JMP32 __BPF_FEATURE_JMP_EXT

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

>> Jose E. Marchesi writes: >> >>> Hi Cuper. >>> Thanks for the patch. >>> >>>> This patch adds line_info debug information support to .BTF.ext >>>> sections. >>>> Line info information is used by the BPF verifier t

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

> Jose E. Marchesi writes: > >> Hi Cuper. >> Thanks for the patch. >> >>> This patch adds line_info debug information support to .BTF.ext >>> sections. >>> Line info information is used by the BPF verifier to improve error >>> r

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

Hi Cuper. Thanks for the patch. > This patch adds line_info debug information support to .BTF.ext > sections. > Line info information is used by the BPF verifier to improve error > reporting and give more precise source core referenced errors. > > gcc/Changelog: > *

Re: [PATCH 1/3] bpf: support more instructions to match CO-RE relocations

Hi Cupertino. OK for master. Thanks! > BPF supports multiple instructions to be CO-RE relocatable regardless of > the position of the immediate field in the encoding. > In particular, not only the MOV instruction allows a CO-RE > relocation of its immediate operand, but the LD and ST

Re: [PATCH] bpf: define INT8_TYPE as signed char

Hi David. > Change the BPF backend to define INT8_TYPE with an explicit sign, rather > than a plain char. This is in line with other targets and removes the > risk of int8_t being affected by the signedness of the plain char type > of the host system. OK. I would add to the commit message

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

>> Jose E. Marchesi writes: >> >>>> This patch corrects bugs within the CO-RE builtin field expression >>>> related builtins. >>>> The following bugs were identified and corrected based on the expected >>>> results of bpf-next s

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

> Jose E. Marchesi writes: > >>> This patch corrects bugs within the CO-RE builtin field expression >>> related builtins. >>> The following bugs were identified and corrected based on the expected >>> results of bpf-next selftests testsuit

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

> This patch corrects bugs within the CO-RE builtin field expression > related builtins. > The following bugs were identified and corrected based on the expected > results of bpf-next selftests testsuite. > It addresses the following problems: > - Expressions with pointer dereferencing now

Re: [PATCH v2] bpf: add size threshold for inlining mem builtins

Hi Faust. OK. Thanks! > [Changes from v1: > - Error if threshold is exceeded instead of silently emitting libcall > - Update test accordingly > - Expand documentation to explain this behavior ] > > BPF cannot fall back on library calls to implement memmove, memcpy and > memset, so we

Re: [PATCH] bpf: add size threshold for inlining mem builtins

Hi Faust. > BPF cannot fall back on library calls to implement memmove, memcpy and > memset, so we attempt to expand these inline always if possible. > However, this inline expansion was being attempted even for excessively > large operations, which could result in gcc consuming huge amounts of

Re: [PATCH] bpf: testsuite: fix unresolved test in memset-1.c

Hi David. OK. Thanks. > The test was trying to do too much by both checking for an error, and > checking the resulting assembly. Of course, due to the error no asm was > produced, so the scan-asm went unresolved. Split it into two separate > tests to fix the issue. > > Tested on

Re: [PATCH] bpf: add inline memset expansion

Hi David. Thanks for the patch. OK. > Similar to memmove and memcpy, the BPF backend cannot fall back on a > library call to implement __builtin_memset, and should always expand > calls to it inline if possible. > > This patch implements simple inline expansion of memset in the BPF > backend in

Re: [PATCH v3] bpf: add inline memmove and memcpy expansion

Hi David. This is OK. Thank you, very nice stuff! > [Changes from v2: > - Fix incorrectly passing a location instead of OPT_W* for warning (). > - Reword warning/error message and test accordingly. ] > > [Changes from v1: Jose's review comments, all of which I agree with. > - Fix

Re: [PATCH v2] bpf: add inline memmove and memcpy expansion

Hi Faust. > +bool > +bpf_expand_cpymem (rtx *operands, bool is_move) > +{ > + /* Size must be constant for this expansion to work. */ > + if (!CONST_INT_P (operands[2])) > +{ > + const char *name = is_move ? "memmove" : "memcpy"; > + if (flag_building_libgcc) > + warning

Re: [PATCH] bpf: Add documentation for the -mcpu option

Hello Will. Thanks for the patch. I just installed it on your behalf. > Add documentation describing the meaning and values for the -mcpu > command-line option. > > Tested for bpf-unknown-none on x86_64-linux-gnu host. > > gcc/ChangeLog: > > * config/bpf/bpf.opt: Add help information for

Re: [PATCH] bpf: add inline memmove and memcpy expansion

Hi David. Thanks for the patch. See a couple of comments regarding error handling below. > BPF programs are not typically linked, which means we cannot fall back > on library calls to implement __builtin_{memmove,memcpy} and should > always expand them inline if possible. > > GCC already

Re: [PATCH] bpf: fix zero_extendqidi2 ldx template

Hi Faust. OK, thank you. > Commit 77d0f9ec3809b4d2e32c36069b6b9239d301c030 inadvertently changed > the normal asm dialect instruction template for zero_extendqidi2 from > ldxb to ldxh. Fix that. > > Tested for bpf-unknown-none on x86_64-linux-gnu host. > > gcc/ > > * config/bpf/bpf.md

[COMMITTED] bpf: emit empty epilogues in naked functions

This patch fixes the BPF backend to not generate `exit' (return) instructions in epilogues of functions that are declared as naked via the corresponding compiler attribute. Having extra exit instructions upsets the kernel BPF verifier. Tested in bpf-unknown-none target in x86_64-linux-gnu host.

[COMMITTED] bpf: add constant pointer to helper-skb-ancestor-cgroup-id.c test

The purpose of this test is to make sure that constant propagation is achieved with the proper optimization level, so a BPF call instruction to a kernel helper is generated. This patch updates the patch so it also covers kernel helpers defined with constant static pointers. The motivation for

Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64

>> mcmodel=large s not supported (yet) on any Darwin arch [PR90698], so > the test needs skipping or xfailing, I think (either way with a > reference to the PR). > > Pushed as > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b74981b5cf32ebf4bfffd25e7174b5c80243447a Thanks for fixing this.

Re: [PATCH] btf: fix PR debug/112656

> Hi Indu. > This is OK. Thanks. Oops sorry scratch that, I am no reviewer for the BTF area. Will have to wait for Faust or someone else to chime in :) > >> PR debug/112656 - btf: function prototypes generated with name >> >> With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in

Re: [PATCH] btf: fix PR debug/112656

Hi Indu. This is OK. Thanks. > PR debug/112656 - btf: function prototypes generated with name > > With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the > generated BTF section. > > As noted in the discussion in the bugzilla, the number of > BTF_KIND_FUNC_PROTO types output

[COMMITTED] bpf: quote section names whenever necessary in assembly output

In BPF section names are used to encode the kind of BPF program and other metadata, involving all sort of non alphanumeric characters. For example: /* use auto-attach format for section definition. */ SEC("uretprobe//proc/self/exe:trigger_func2") int handle_uretprobe_byname(struct pt_regs

Re: [PATCH] bpf: change ASM_COMMENT_START to '#'

Hi David. OK. Thanks. > The BPF "pseudo-C" assembly dialect uses semi-colon (;) to separate > statements, not to begin line comments. The GNU assembler was recently > changed accordingly: > > https://sourceware.org/pipermail/binutils/2023-November/130867.html > > This patch adapts the BPF

Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64

> On Wed, Nov 29, 2023 at 09:20:55AM +0100, Jose E. Marchesi wrote: >> OK to the patch below? >> >> >From a697f9e9442d96d3eda228b825dd8e8e06206c03 Mon Sep 17 00:00:00 2001 >> From: "Jose E. Marchesi" >> Date: Wed, 29 Nov 2023 09:16:48 +0100 >

Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64

> On Wed, Nov 29, 2023 at 07:51:15AM +0100, Jose E. Marchesi wrote: >> > FAIL: gcc.c-torture/compile/libcall-2.c -O1 (test for excess errors) >> > FAIL: gcc.c-torture/compile/libcall-2.c -O2 -flto >> > -fno-use-linker-plugin -flto-partition=none (test for e

Re: [r14-5930 Regression] FAIL: gcc.c-torture/compile/libcall-2.c -Os (test for excess errors) on Linux/x86_64

> On Linux/x86_64, > > f31a019d1161ec78846473da743aedf49cca8c27 is the first bad commit > commit f31a019d1161ec78846473da743aedf49cca8c27 > Author: Jose E. Marchesi > Date: Fri Nov 24 06:30:28 2023 +0100 > > Emit funcall external declarations only if actually u

Re: [PATCH] Emit funcall external declarations only if actually used.

>> "Jose E. Marchesi" writes: >>> There are many places in GCC where alternative local sequences are >>> tried in order to determine what is the cheapest or best alternative >>> to use in the current target. When any of these sequences involv

Re: bpf: Throw error when external libcalls are generated.

> Hi Cuper. > OK. Thanks for the patch. This commit is breaking the BPF build, because libgcc emits libcalls to __builtin_abort. We need to rethink this. Please revert: commit faf5b148588bd7fbb60ec669aefa704044037cdc Author: Cupertino Miranda Date: Thu Nov 23 22:28:01 2023 +

Re: [PATCH] Emit funcall external declarations only if actually used.

> "Jose E. Marchesi" writes: >> There are many places in GCC where alternative local sequences are >> tried in order to determine what is the cheapest or best alternative >> to use in the current target. When any of these sequences involve a >>

Re: bpf: Throw error when external libcalls are generated.

Hi Cuper. OK. Thanks for the patch. > Hi everyone, > > The attached patch is a temporary solution for the lack of proper linker > and external library linking of the eBPF platform. > Any calls created by the compiler, that would usually be defined within > libgcc, will endup being undefined in

[COMMITTED] bpf: remove bpf-helpers.h

Now that we are finally able to use the kernel provided bpf_helpers.h file and associated machinery, there is no longer need to distribute our own version. This patch removes bpf-helpers.h and deletes most of the associated tests from the gcc.target/bpf testsuite. Two tests are adapted and

[PATCH] Emit funcall external declarations only if actually used.

There are many places in GCC where alternative local sequences are tried in order to determine what is the cheapest or best alternative to use in the current target. When any of these sequences involve a libcall, the current implementation of emit_library_call_value_1 introduce a side-effect

Re: [PATCH] bpf: Forces __buildin_memcmp not to generate a call upto 1024 bytes.

Hi Cuper. Sorry, I missed this patch last week. This is OK. Thanks! > This patch forces __builtin_memcmp calls upto data sizes of 1024 to > become inline in caller. > This is a requirement by BPF and it mimics the default behaviour of the > clang BPF implementation. > > gcc/ChangeLog: >

Re: [PATCH V2] libgcc: mark __hardcfr_check_fail as always_inline

>> Am 23.11.2023 um 16:17 schrieb Jose E. Marchesi : >> >> [Changes from V1: >> - Use always_inline only in BPF target.] >> >> The function __hardcfr_check_fail in hardcfr.c is internal and static >> inline. It receives many arguments, which requir

[PATCH V2] libgcc: mark __hardcfr_check_fail as always_inline

[Changes from V1: - Use always_inline only in BPF target.] The function __hardcfr_check_fail in hardcfr.c is internal and static inline. It receives many arguments, which require more than five registers to be passed in bpf-none-unknown targets. BPF is limited to that number of registers to

Re: [PATCH] libgcc: mark __hardcfr_check_fail as always_inline

> On Wed, Nov 22, 2023 at 3:39 PM Jose E. Marchesi > wrote: >> >> The function __hardcfr_check_fail in hardcfr.c is internal and static >> inline. It receives many arguments, which require more than five >> registers to be passed in bpf-none-unknown targets. BP

[PATCH] libgcc: mark __hardcfr_check_fail as always_inline

The function __hardcfr_check_fail in hardcfr.c is internal and static inline. It receives many arguments, which require more than five registers to be passed in bpf-none-unknown targets. BPF is limited to that number of registers to pass arguments, and therefore libgcc fails to build in that

[COMMITTED] bpf: fix pseudo-c asm emitted for *mulsidi3_zeroextend

This patch fixes the pseudo-c BPF assembly syntax used for *mulsidi3_zeroextend, which was being emitted as: rN *= wM instead of the proper way to denote a mul32 in pseudo-C syntax: wN *= wM Includes test. Tested in bpf-unknown-none-gcc target in x86_64-linux-gnu host. gcc/ChangeLog:

[COMMITED] bpf: testsuite: fix expected regexp in gcc.target/bpf/ldxdw.c

gcc/testsuite/ChangeLog: * gcc.target/bpf/ldxdw.c: Fix regexp with expected result. --- gcc/testsuite/gcc.target/bpf/ldxdw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.target/bpf/ldxdw.c b/gcc/testsuite/gcc.target/bpf/ldxdw.c index

Re: RFC (V2) the proposal to resolve the missing dependency issue for counted_by attribute

> On Thu, Nov 09, 2023 at 03:49:49PM +, Qing Zhao wrote: >> Is it reasonable to add one option to disable the “counted_by” attribute? >> (then no insertion of the new .ACCESS_WITH_SIZE into IL). >> >> The major reason is: some users might want to ignore all the “counted_by” >> attribute

Re: __hardcfr_check_fail and BPF

> Hi, > > On Oct 31, 2023, "Jose E. Marchesi" wrote: > >> As you may know, in BPF we have to live (for now) with the constant pain >> from being limited to functions whose arguments can be compiled to get >> their arguments in five or less registers. &g

__hardcfr_check_fail and BPF

Hi Alex. As you may know, in BPF we have to live (for now) with the constant pain from being limited to functions whose arguments can be compiled to get their arguments in five or less registers. The recently introduced __hardcfr_check_fail in the run-time component of hardcfr breaks the

Re: [PATCH] gcov-io.h: fix comment regarding length of records

> On 10/24/23 06:41, Jose E. Marchesi wrote: >> The length of gcov records is stored as a signed 32-bit number of >> bytes. >> Ok? > OK. Pushed. Thanks.

[PATCH] gcov-io.h: fix comment regarding length of records

The length of gcov records is stored as a signed 32-bit number of bytes. Ok? diff --git a/gcc/gcov-io.h b/gcc/gcov-io.h index bfe4439d02d..e6f33e32652 100644 --- a/gcc/gcov-io.h +++ b/gcc/gcov-io.h @@ -101,7 +101,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see

Re: [PATCH V2] Emit funcall external declarations only if actually used.

> "Jose E. Marchesi" writes: >> Hi Richard. >> Thanks for looking at this! :) >> >> >>> "Jose E. Marchesi" writes: >>>> ping >>> >>> I don't know this code very well, and have AFAIR haven't worked >>

Re: [PATCH V2] Emit funcall external declarations only if actually used.

Hi Richard. Thanks for looking at this! :) > "Jose E. Marchesi" writes: >> ping > > I don't know this code very well, and have AFAIR haven't worked > with an assembler that requires external declarations, but since > it's at a second ping :) > >>

Re: [PATCH V2] Emit funcall external declarations only if actually used.

ping > ping > >> [Differences from V1: >> - Prototype for call_from_call_insn moved before comment block. >> - Reuse the `call' flag for SYMBOL_REF_LIBCALL. >> - Fallback to check REG_CALL_DECL in non-direct calls. >> - New test to check correct behavior for non-direct calls.] >> >> There are

Re: [PATCH V2] Emit funcall external declarations only if actually used.

ping^ > ping > >> [Differences from V1: >> - Prototype for call_from_call_insn moved before comment block. >> - Reuse the `call' flag for SYMBOL_REF_LIBCALL. >> - Fallback to check REG_CALL_DECL in non-direct calls. >> - New test to check correct behavior for non-direct calls.] >> >> There are

Re: [PATCH V2] Emit funcall external declarations only if actually used.

ping > [Differences from V1: > - Prototype for call_from_call_insn moved before comment block. > - Reuse the `call' flag for SYMBOL_REF_LIBCALL. > - Fallback to check REG_CALL_DECL in non-direct calls. > - New test to check correct behavior for non-direct calls.] > > There are many places in

Re: [PATCH V4] Add warning options -W[no-]compare-distinct-pointer-types

Hi Marek. > On Thu, Aug 17, 2023 at 05:37:03PM +0200, Jose E. Marchesi via Gcc-patches > wrote: >> >> > On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote: >> > >> >> +@opindex Wcompare-distinct-pointer-types >> >> +@item -Wcomp

Re: [PATCH] bpf: neg instruction does not accept an immediate

> The BPF virtual machine does not support neg nor neg32 instructions with > an immediate. > > The erroneous instructions were removed from binutils: > https://sourceware.org/pipermail/binutils/2023-August/129135.html > > Change the define_insn so that an immediate cannot be accepted. > > From

[PATCH V2] Emit funcall external declarations only if actually used.

[Differences from V1: - Prototype for call_from_call_insn moved before comment block. - Reuse the `call' flag for SYMBOL_REF_LIBCALL. - Fallback to check REG_CALL_DECL in non-direct calls. - New test to check correct behavior for non-direct calls.] There are many places in GCC where alternative

Re: [PATCH] Emit funcall external declarations only if actually used.

Hi Jakub. Thanks for the review. > On Fri, Aug 18, 2023 at 03:53:51PM +0200, Jose E. Marchesi via Gcc-patches > wrote: >> --- a/gcc/final.cc >> +++ b/gcc/final.cc >> @@ -815,6 +815,8 @@ make_pass_compute_alignments (gcc::context *ctxt) >> reorg.cc, since th

[PATCH] Emit funcall external declarations only if actually used.

[Previous thread: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608162.html] There are many places in GCC where alternative local sequences are tried in order to determine what is the cheapest or best alternative to use in the current target. When any of these sequences involve a

[COMMITTED] bpf: bump maximum frame size limit to 32767 bytes

This commit bumps the maximum stack frame size allowed for BPF functions to the maximum possible value. Tested in x86_64-linux-gnu host and target bpf-unknown-none. gcc/ChangeLog * config/bpf/bpf.opt (mframe-limit): Set default to 32767. gcc/testsuite/ChangeLog *

Re: [PATCH V4] Add warning options -W[no-]compare-distinct-pointer-types

> On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote: > >> +@opindex Wcompare-distinct-pointer-types >> +@item -Wcompare-distinct-pointer-types > > This @item should say @r{(C and Objective-C only)}, since the option isn't > implemented for C++. O

[PATCH V4] Add warning options -W[no-]compare-distinct-pointer-types

[Changes from V3: - Previous thread: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600625.html - The tests have been augmented to check all six relational operators. In particular it covers both code paths impacted by the patch: the equality/inequality and the relational ops.] GCC

[COMMITTED] bpf: support `naked' function attributes in BPF targets

The kernel selftests and other BPF programs make extensive use of the `naked' function attribute with bodies written using basic inline assembly. This patch adds support for the attribute to bpf-unkonwn-none, makes it to inhibit warnings due to lack of explicit `return' statement, and updates

Re: [PATCH] bpf: fix pseudoc w regs for small modes [PR111029]

> On Tue, Aug 15, 2023 at 9:03 PM Jose E. Marchesi via Gcc-patches > wrote: >> >> >> Hello David. >> Thanks for the patch. >> >> OK. > > Picking a random patch/mail for this question - how do we maintain BPF > support for the most recent GCC

Re: [PATCH] bpf: remove useless define_insn for extendsisi2

OK. Thanks! > This define_insn is never used, since a sign-extend to the same mode is > just a move, so delete it. > > Tested on x86_64-linux-gnu host for bpf-unknown-none target. > > gcc/ > > * config/bpf/bpf.md (extendsisi2): Delete useless define_insn. > --- > gcc/config/bpf/bpf.md |

Re: [PATCH] bpf: fix pseudoc w regs for small modes [PR111029]

Hello David. Thanks for the patch. OK. > In the BPF pseudo-c assembly dialect, registers treated as 32-bits > rather than the full 64 in various instructions ought to be printed as > "wN" rather than "rN". But bpf_print_register () was only doing this > for specifically SImode registers,

[COMMITTED] bpf: liberate R9 for general register allocation

We were reserving one of the hard registers in BPF in order to implement dynamic stack allocation: alloca and VLAs. However, there is kernel code that has inline assembly that requires all the non-fixed registers to be available for register allocation. This patch: 1. Liberates r9 that is now

[COMMITTED] bpf: allow exceeding max num of args in BPF when always_inline

BPF currently limits the number of registers used to pass arguments to functions to five registers. There is a check for this at function expansion time. However, if a function is guaranteed to be always inlined (and its body never generated) by virtue of the always_inline attribute, it can

Re: [PATCH] bpf: Fixed GC mistakes in BPF builtins code.

Hi Cuper. OK. Hopefully all the roots are marked now to avoid these nodes being collected. Thanks. > Hi everyone, > > This patch fixes BPF CO-RE builtins support that missed information for > garbage collector (GC). > > The BPF CO-RE implementation defines several data structures that keep >

Re: [v2 PATCH 2/2] bpf: CO-RE builtins support tests.

OK. Thanks. > Hi, > > Resending this patch since I have noticed I had a testcase added in > previous patch. Makes more sense here. > > Thanks, > Cupertino > > From 334e9ae0f428f6573f2a5e8a3067a4d181b8b9c5 Mon Sep 17 00:00:00 2001 > From: Cupertino Miranda > Date: Thu, 27 Jul 2023 18:05:22

Re: [v2 PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

Ok. Thanks! > From fda9603ded735205b6e20fc5b65a04f8d15685e6 Mon Sep 17 00:00:00 2001 > From: Cupertino Miranda > Date: Thu, 6 Apr 2023 15:22:48 +0100 > Subject: [PATCH v2 1/2] bpf: Implementation of BPF CO-RE builtins > > This patch updates the support for the BPF CO-RE builtins >

Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

> Jose E. Marchesi writes: > >>> This patch updates the support for the BPF CO-RE builtins >>> __builtin_preserve_access_index and __builtin_preserve_field_info, >>> and adds support for the CO-RE builtins __builtin_btf_type_id, >>> __builtin_preserve_t

Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

> This patch updates the support for the BPF CO-RE builtins > __builtin_preserve_access_index and __builtin_preserve_field_info, > and adds support for the CO-RE builtins __builtin_btf_type_id, > __builtin_preserve_type_info and __builtin_preserve_enum_value. > > These CO-RE relocations are now

[COMMITTED] bpf: disable tail call optimization in BPF targets

clang disables tail call optimizations in BPF targets. Do the same in GCC. gcc/ChangeLog: * config/bpf/bpf.cc (bpf_option_override): Disable tail-call optimizations in BPF target. --- gcc/config/bpf/bpf.cc | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH] bpf: ISA V4 sign-extending move and load insns [PR110782,PR110784]

Hi David. Thanks for the patch. > BPF ISA V4 introduces sign-extending move and load operations. This > patch makes the BPF backend generate those instructions, when enabled > and useful. > > A new option, -m[no-]smov gates generation of these instructions, and is > enabled by default for

Re: [PATCH] bpf: minor doc cleanup for command-line options

Hi David, thanks for the patch. OK. > This patch makes some minor cleanups to eBPF options documented in > invoke.texi: > - Delete some vestigal docs for removed -mkernel option > - Add -mbswap and -msdiv to the option summary > - Note the negative versions of several options > - Note that

Re: [PATCH] bpf: correct pseudo-C template for add3 and sub3

> The pseudo-C output templates for these instructions were incorrectly > using operand 1 rather than operand 2 on the RHS, which led to some > very incorrect assembly generation with -masm=pseudoc. > > Tested on bpf-unknown-none. > OK? OK. Thanks for spotting and fixing this! > > gcc/ > >

Re: [PATCH v2 2/2] bpf: add v3 atomic instructions

OK. Thanks! > [Changes from v1: fix merge issue in invoke.texi] > > This patch adds support for the general atomic operations introduced in > eBPF v3. In addition to the existing atomic add instruction, this adds: > - Atomic and, or, xor > - Fetching versions of these operations (including

[COMMITTED] bpf: fix generation of neg and neg32 BPF instructions

This patch fixes GCC to generate correct neg and neg32 instructions, which do not take a source register operand. A couple of new tests are added. Tested in bpf-unknown-none. gcc/ChangeLog 2023-07-26 Jose E. Marchesi * config/bpf/bpf.md: Fix neg{SI,DI}2 insn. gcc/testsuite

Re: [PATCH 2/2] bpf: add v3 atomic instructions

Hi David. > +<<< HEAD There is a merge problem there. > @opindex mbswap > @item -mbswap > Enable byte swap instructions. Enabled for CPU v4 and above. > @@ -24715,6 +24716,12 @@ Enable byte swap instructions. Enabled for CPU v4 > and above. > @item -msdiv > Enable signed division

Re: [PATCH 1/2] bpf: don't print () in bpf_print_operand_address

Hi David. > Unfortunately, the pseudo-C dialect syntax used for some of the v3 > atomic instructions clashes with unconditionally printing the > surrounding parentheses in bpf_print_operand_address. > > Instead, place the parentheses in the output templates where needed. > > Tested in

Re: [COMMITTED] bpf: add pseudo-c asm dialect for "nop"

> The define_insn "nop" was missing a template for the pseudo-c dialect, > so the normal syntax was unconditionally emitted. Thank you. > Tested on bpf-unknown-none, committed as obvious. > > gcc/ > > * config/bpf/bpf.md (nop): Add pseudo-c asm dialect template. > --- >

[COMMITTED] bpf: sdiv/smod are now part of BPF V4

We used to support signed division and signed modulus instructions in the XBPF GCC-specific extensions to BPF. However, BPF catched up by adding these instructions in the V4 of the ISA. This patch changes GCC in order to use sdiv/smod instructions when -mcpu=v4 or higher. The testsuite and the

[COMMITTED] bpf: remove -mkernel option and BPF_KERNEL_VERSION_CODE

Having the ability of specifying a target kernel version when building a BPF program is one of these things that sound pretty good in theory, but simply don't work in practice: kernels in practice contain backports, etc. Also, the addition of CO-RE to BPF has made this uneccessary. This patch

[COMMITTED] bpf: make use of the bswap{16,32,64} V4 BPF instruction

This patch makes the BPF backend to use the new V4 bswap{16,32,64} instructions in order to implement the __builtin_bswap{16,32,64} built-ins. It also adds support for -mcpu=v4 and -m[no]bswap command-line options. Tests and doc updates are includes. Tested in bpf-unknown-none. gcc/ChangeLog

Re: [PATCH v4] bpf: fixed template for neg (added second operand)

Better with the commit message. OK. Thanks. > This patch fixes define_insn for "neg" to support 2 operands. > Initial implementation assumed the format "neg %0" while the instruction > allows both a destination and source operands. The second operand can > either be a register or an immediate

Re: [PATCH v3] bpf: fixed template for neg (added second operand)

Hi Cuper. OK. Thanks! > From 7756a4becd1934e55d6d14ac4a9fd6d408a4797b Mon Sep 17 00:00:00 2001 > From: Cupertino Miranda > Date: Fri, 21 Jul 2023 17:40:07 +0100 > Subject: [PATCH v3] bpf: fixed template for neg (added second operand) > > gcc/ChangeLog: > > * config/bpf/bpf.md: fixed

Re: [PATCH v3] bpf: pseudo-c assembly dialect support

> Thanks for the suggestions/fixes in changelog. > Inlined new patch. > > Cupertino > >>> gcc/ChangeLog: >>> >>> * config/bpf/bpf.opt: Added option -masm=. >>> * config/bpf/bpf-opts.h: Likewize. >>> * config/bpf/bpf.cc: Changed it to conform with new pseudoc >>> dialect

Re: [PATCH v2] bpf: pseudo-c assembly dialect support

> gcc/ChangeLog: > > * config/bpf/bpf.opt: Added option -masm=. > * config/bpf/bpf-opts.h: Likewize. > * config/bpf/bpf.cc: Changed it to conform with new pseudoc > dialect support. > * config/bpf/bpf.h: Likewise. > * config/bpf/bpf.md: Added pseudo-c

Re: [PATCH] bpf: pseudo-c assembly dialect support

Hello Cuper. Thanks for the patch. We will need an update for the "eBPF Options" section in the GCC manual, documenting -masm=@var{dialect} and the supported values. Can you please add it and re-submit? > Hi everyone, > > Looking forward to all your reviews. > > Best regards, > Cupertino >

[COMMITTED] bpf: enable instruction scheduling

commit 53d12ecd624ec901d8449cfa1917f6f90e910927 (HEAD -> master, origin/master, origin/HEAD) Author: Jose E. Marchesi Date: Fri Jul 14 13:54:06 2023 +0200 bpf: enable instruction scheduling This patch adds a dummy FSM to bpf.md in order to get INSN_SCHEDULING defi

Re: [PATCH 0/9] Add btf_decl_tag C attribute

> On Wed, Jul 12, 2023 at 2:44 PM Jose E. Marchesi > wrote: >> >> >> [Added Eduard Zingerman in CC, who is implementing this same feature in >> clang/llvm and also the consumer component in the kernel (pahole).] >> >> Hi Richard. >> >>

Re: [PATCH 0/9] Add btf_decl_tag C attribute

[Added Eduard Zingerman in CC, who is implementing this same feature in clang/llvm and also the consumer component in the kernel (pahole).] Hi Richard. > On Tue, Jul 11, 2023 at 11:58 PM David Faust via Gcc-patches > wrote: >> >> Hello, >> >> This series adds support for a new attribute,

Re: [committed] Docs: Fix formatting issues in BPF built-ins documentation

Hi Sandra. > This section of the GCC manual had some issues with lines in the > example overflowing into the right margin of the PDF-format document, > but as I looked at it more closely I also saw that it was full of > missing or incorrect Texinfo markup, too. I've cleaned it up thusly.

Re: [patch] bpf: Fix double whitespace warning

> Hi! > > Since a recent commit, the BPF target produces a new warning due to > two consecutive non-quoted spaces in a message. This'll fix it: > > gcc/ > * config/bpf/bpf.cc (bpf_option_override): Fix doubled space. > > > Ok? OK. Thanks for the patch. (Sorry I didn't fix this when you

Re: [PATCH] bpf: fix memory constraint of ldx/stx instructions [PR108790]

Hi David. > In some cases where the target memory address for an ldx or stx > instruction could be reduced to a constant, GCC could emit a malformed > instruction like: > > ldxdw %r0,0 > > Rather than the expected form: > > ldxdw %rX, [%rY + OFFSET] > > This is due to the constraint

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

> On Thu, Dec 8, 2022 at 2:56 AM Jose E. Marchesi via Gcc-patches > wrote: >> >> The expand_expr_divmod function in expr.cc attempts to optimize cases >> where both arguments of a division/modulus are known to be positive >> when interpreted as signed. In the

[COMMITTED] bpf: disable -fstack-protector in BPF

The stack protector is not supported in BPF. This patch disables -fstack-protector in bpf-* targets, along with the emission of a note indicating that the feature is not supported in this platform. Regtested in bpf-unknown-none. gcc/ChangeLog: * config/bpf/bpf.cc (bpf_option_override):

Re: [PATCH,WWWDOCS] htdocs: add an Atom feed for GCC news

> On Wed, 11 Jan 2023, Thomas Schwinge wrote: >> On 2022-12-23T10:50:13+0100, "Jose E. Marchesi via Gcc-patches" >> wrote: >>> This patch adds an Atom feed for GCC news, which can then be easily >>> aggregated in other sites, such as the GNU

  1   2   3   4   5   >