[cfe-dev] Disable certain llvm optimizations at clang frontend

[Alexei Starovoitov via cfe-dev]

On Mon, Jun 22, 2020 at 11:19 PM Eli Friedman <efriedma at quicinc.com> wrote:
>
> > -----Original Message-----
> > From: Y Song <ys114321 at gmail.com>
> > Sent: Monday, June 22, 2020 10:29 PM
> > To: Hal Finkel <hfinkel at anl.gov>
> > Cc: Eli Friedman <efriedma at quicinc.com>; cfe-dev <cfe-dev at lists.llvm.org>;
> > Andrii Nakryiko <andrii.nakryiko at gmail.com>; Alexei Starovoitov
> > <ast at kernel.org>
> > Subject: [EXT] Re: [cfe-dev] Disable certain llvm optimizations at clang
> > frontend
> >
> > On Mon, Jun 22, 2020 at 3:42 PM Hal Finkel <hfinkel at anl.gov> wrote:
> > > Thanks, this is helpful. One question: Is the information used by the
> > > verifier available at compile time? It seems like what you want here is
> >
> > We have identified some compiler optimizations in instcombine and
> > simplifyCFG may generate verifier unfriendly code. Yes, we could do
> > IR analysis to identify these patterns, may not be 100% but should be
> > close.
> >
> > Completely modelling what verifier did in llvm is complex. Verifier
> > interacts with kernel subsystem with helper functions and these
> > helper functions having some semantics utilized with the verifier.
> > Bringing kernel helpers to llvm does not sound a good idea.
> > Verifier implements a path sensitive verification framework. To replicate
> > in llvm probably not a good idea as there are constant changes to
> > verifier and it is very hard to keep them sync. So here, in llvm the
> > best probably
> > to identify known IR patterns where verifier unfriendly code may be
> > generated and prevent them from generating (preferred) or undo them
> > if already generated.
>
> We don't necessarily need to know the exact rules; some sort of conservative approximation is fine.  We do need some model at the LLVM IR level, so we can document the rules transforms need to follow.
>
> It would be preferable to have rules that don't require modifying the semantics of existing instructions. That's not a hard requirement, but the further you go from the usual LLVM model, the bigger the maintenance burden.
>
> > Two more ideas here:
> > (1). Is it possible to implement an generic IR pass (before InstCombine
> > and SimplifyCFG) which takes some hints from backend to modify IR
> > to favor BPF verifier?
>
> See addCoroutinePassesToExtensionPoints.

Thanks for the suggestion.
Another way of thinking about it is to treat the kernel consumed assembly
as output of C dialect.
Like the coroutine is a language feature.
And the C language used to write BPF programs verified by the kernel
is a subset of C. We use special builtins for CO-RE. It's a C language
extension to some degree.
Similarly not every C construct is supported. We still cannot do indirect calls.
swich statement with jump table is not supported either.
If we can tell clang that C with '-target bpf' is actually somewhat different C
that would fit nicely into LangOpts model.