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

[Y Song 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 pointer! Will take a look.

>
> > (2). is it possible that clang frontend provides a hook for target to
> > provide a pass manager or at least having a say
> > to the pass manager? This way, target may disable certain passes?
> > I realize this is a big hammer approach. But Considering here that our
> > main goal is to improve development experience and performance
> > is not a goal, maybe it is still acceptable?
>
> I don't think it makes sense to provide a way to disable a pass by name.  My primary concern here is maintainability.  Nobody working on target-independent code is going to understand why the passes are disabled.  If someone changes the pass responsible for a transform, it isn't reasonable to say that involves updating random backends.

Okay. Understand. My original thinking is that the burden for
maintenance lays on BPF backend. If anything in target independent
code breaks anything, it is BPF backend's responsibility to adjust its
pass manager. Putting any burden on generic optimization is surely not
reasonable.

I think your reference above to addCoroutinePassesToExtensionPoints
might provide a way for
BPF backend to tweak IR before major optimizations so that verifier
friendly code can be generated.

>
> -Eli