From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: David Faust <david.faust@oracle.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] bpf: fix pseudoc w regs for small modes [PR111029]
Date: Thu, 17 Aug 2023 11:15:37 +0200 [thread overview]
Message-ID: <87il9eyqpy.fsf@oracle.com> (raw)
In-Reply-To: <CAFiYyc0kvcsVv2GX2Cu+HEKM1wGrh4dRP6_RNqEJw01nh6hx_Q@mail.gmail.com> (Richard Biener's message of "Thu, 17 Aug 2023 10:44:23 +0200")
> On Tue, Aug 15, 2023 at 9:03 PM Jose E. Marchesi via Gcc-patches
> <gcc-patches@gcc.gnu.org> 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 release which is GCC 13? I see the
> current state in GCC 13 isn't fully able to provide upstream kernel BPF
> support but GCC 14 contains some bugfixes and some new features(?).
> Is it worthwhile to backport at least bugfixes while GCC 14 is still in
> development even if those are not regression fixes? Or is GCC 13 BPF
> too broken to be used anyway?
Our plan is:
1. Get git GCC and git binutils to compile all the kernel BPF selftests.
This covers both functionality (builtins, attributes, BTF, CO-RE,
etc) and consolidation of behavior between the GNU and llvm bpf
ports. We are working very hard to achieve this point and we are
very near: functionality wise we are on-par in all components, but
there are some bugs we are fixing. We expect to be done in a couple
of weeks.
2. Once the above is achieved, we plan to start doing the backports to
released/maintained versions of both binutils and GCC so distros like
Debian (that already package gcc-bpf) can use the toolchain.
3. Next step is to make sure the compiler generates code that can
generally satisfy the many restrictions imposed by the kernel
verifier, at least to a point that is practical. This is a difficult
general problem not specific to GCC and is shared by llvm and other
optimizing compilers, sort of a moving target, and it is not clear at
all how to achieve this in a general and practical way. We have some
ideas and have submitted a proposal to discuss this topic during this
year's Cauldron: "The challenge of compiling for verified targets".
> Thanks,
> Richard.
>
>> > 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, meaning smaller modes were printed
>> > incorrectly.
>> >
>> > This caused assembler errors like:
>> >
>> > Error: unrecognized instruction `w2 =(s8)r1'
>> >
>> > for a 32-bit sign-extending register move instruction, where the source
>> > register is used in QImode.
>> >
>> > Fix bpf_print_register () to print the "w" version of register when
>> > specified by the template for any mode 32-bits or smaller.
>> >
>> > Tested on bpf-unknown-none.
>> >
>> > PR target/111029
>> >
>> > gcc/
>> > * config/bpf/bpf.cc (bpf_print_register): Print 'w' registers
>> > for any mode 32-bits or smaller, not just SImode.
>> >
>> > gcc/testsuite/
>> >
>> > * gcc.target/bpf/smov-2.c: New test.
>> > * gcc.target/bpf/smov-pseudoc-2.c: New test.
>> > ---
>> > gcc/config/bpf/bpf.cc | 2 +-
>> > gcc/testsuite/gcc.target/bpf/smov-2.c | 15 +++++++++++++++
>> > gcc/testsuite/gcc.target/bpf/smov-pseudoc-2.c | 15 +++++++++++++++
>> > 3 files changed, 31 insertions(+), 1 deletion(-)
>> > create mode 100644 gcc/testsuite/gcc.target/bpf/smov-2.c
>> > create mode 100644 gcc/testsuite/gcc.target/bpf/smov-pseudoc-2.c
>> >
>> > diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
>> > index 3516b79bce4..1d0abd7fbb3 100644
>> > --- a/gcc/config/bpf/bpf.cc
>> > +++ b/gcc/config/bpf/bpf.cc
>> > @@ -753,7 +753,7 @@ bpf_print_register (FILE *file, rtx op, int code)
>> > fprintf (file, "%s", reg_names[REGNO (op)]);
>> > else
>> > {
>> > - if (code == 'w' && GET_MODE (op) == SImode)
>> > + if (code == 'w' && GET_MODE_SIZE (GET_MODE (op)) <= 4)
>> > {
>> > if (REGNO (op) == BPF_FP)
>> > fprintf (file, "w10");
>> > diff --git a/gcc/testsuite/gcc.target/bpf/smov-2.c b/gcc/testsuite/gcc.target/bpf/smov-2.c
>> > new file mode 100644
>> > index 00000000000..6f3516d2385
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.target/bpf/smov-2.c
>> > @@ -0,0 +1,15 @@
>> > +/* Check signed 32-bit mov instructions. */
>> > +/* { dg-do compile } */
>> > +/* { dg-options "-mcpu=v4 -O2" } */
>> > +
>> > +int
>> > +foo (unsigned char a, unsigned short b)
>> > +{
>> > + int x = (char) a;
>> > + int y = (short) b;
>> > +
>> > + return x + y;
>> > +}
>> > +
>> > +/* { dg-final { scan-assembler {movs32\t%r.,%r.,8\n} } } */
>> > +/* { dg-final { scan-assembler {movs32\t%r.,%r.,16\n} } } */
>> > diff --git a/gcc/testsuite/gcc.target/bpf/smov-pseudoc-2.c b/gcc/testsuite/gcc.target/bpf/smov-pseudoc-2.c
>> > new file mode 100644
>> > index 00000000000..6af6cadf8df
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.target/bpf/smov-pseudoc-2.c
>> > @@ -0,0 +1,15 @@
>> > +/* Check signed 32-bit mov instructions (pseudo-C asm dialect). */
>> > +/* { dg-do compile } */
>> > +/* { dg-options "-mcpu=v4 -O2 -masm=pseudoc" } */
>> > +
>> > +int
>> > +foo (unsigned char a, unsigned short b)
>> > +{
>> > + int x = (char) a;
>> > + int y = (short) b;
>> > +
>> > + return x + y;
>> > +}
>> > +
>> > +/* { dg-final { scan-assembler {w. = \(s8\) w.\n} } } */
>> > +/* { dg-final { scan-assembler {w. = \(s16\) w.\n} } } */
prev parent reply other threads:[~2023-08-17 9:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 18:46 David Faust
2023-08-15 19:02 ` Jose E. Marchesi
2023-08-17 8:44 ` Richard Biener
2023-08-17 9:15 ` Jose E. Marchesi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87il9eyqpy.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=david.faust@oracle.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).