Re: BPF GCC status - Nov 2023

[Yonghong Song <yonghong.song@linux.dev>]

On 11/29/23 2:08 AM, Jose E. Marchesi wrote:
>> On 11/28/23 11:23 AM, Jose E. Marchesi wrote:
>>> [During LPC 2023 we talked about improving communication between the GCC
>>>    BPF toolchain port and the kernel side.  This is the first periodical
>>>    report that we plan to publish in the GCC wiki and send to interested
>>>    parties.  Hopefully this will help.]
>>>
>>> GCC wiki page for the port: https://gcc.gnu.org/wiki/BPFBackEnd
>>> IRC channel: #gccbpf at irc.oftc.net.
>>> Help on using the port: gcc@gcc.gnu.org
>>> Patches and/or development discussions: gcc-patches@gnu.org
>> Thanks a lot for detailed report. Really helpful to nail down
>> issues facing one or both compilers. See comments below for
>> some mentioned issues.
>>
>>> Assembler
>>> =========
>> [...]
>>
>>> - In the Pseudo-C syntax register names are not preceded by % characters
>>>     nor any other prefix.  A consequence of that is that in contexts like
>>>     instruction operands, where both register names and expressions
>>>     involving symbols are expected, there is no way to disambiguate
>>>     between them.  GAS was allowing symbols like `w3' or `r5' in syntactic
>>>     contexts where no registers were expected, such as in:
>>>
>>>       r0 = w3 ll  ; GAS interpreted w3 as symbol, clang emits error
>>>
>>>     The clang assembler wasn't allowing that.  During LPC we agreed that
>>>     the simplest approach is to not allow any symbol to have the same name
>>>     than a register, in any context.  So we changed GAS so it now doesn't
>>>     allow to use register names as symbols in any expression, such as:
>>>
>>>       r0 = w3 + 1 ll  ; This now fails for both GAS and llvm.
>>>       r0 = 1 + w3 ll  ; NOTE this does not fail with llvm, but it should.
>> Could you provide a reproducible case above for llvm? llvm does not
>> support syntax like 'r0 = 1 + w3 ll'. For add, it only supports
>> 'r1 += r2' or 'r1 += 100' syntax.
> It is a 128-bit load with an expression.  In compiler explorer, clang:
>
>    int
>    foo ()
>    {
>      asm volatile ("r1 = 10 + w3 ll");
>      return 0;
>    }
>
> I get:
>
>    foo:                                    # @foo
>            r1 = 10+w3 ll
>            r0 = 0
>            exit
>
> i.e. `10 + w3' is interpreted as an expression with two operands: the
> literal number 10 and a symbol (not a register) `w3'.
>
> If the expression is `w3+10' instead, your parser recognizes the w3 as a
> register name and errors out, as expected.
>
> I suppose llvm allows to hook on the expression parser to handle
> individual operands.  That's how we handled this in GAS.

Thanks for the code. I can reproduce the result with compiler explorer.
The following is the link https://godbolt.org/z/GEGexf1Pj
where I added -grecord-gcc-switches to dump compilation flags
into .s file.

The following is the compiler explorer compilation command line:
/opt/compiler-explorer/clang-trunk-20231129/bin/clang-18 -g -o /app/output.s \
   -S --target=bpf -fcolor-diagnostics -gen-reproducer=off -O2 \
   -g -grecord-command-line /app/example.c

I then compile the above C code with
   clang -g -S --target=bpf -fcolor-diagnostics -gen-reproducer=off -O2 -g -grecord-command-line t.c
with identical flags.

I tried locally with llvm16/17/18. They all failed compilation since
'r1 = 10+w3 ll' cannot be recognized by the llvm.
We will investigate why llvm18 in compiler explorer compiles
differently from my local build.