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

[Eli Friedman via cfe-dev]

(Reply inline)

> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Y Song via cfe-
> dev
> Sent: Friday, June 19, 2020 11:40 AM
> To: Hal Finkel <hfinkel at anl.gov>
> Cc: Andrii Nakryiko <andrii.nakryiko at gmail.com>; Clang Dev <cfe-
> dev at lists.llvm.org>; Alexei Starovoitov <ast at kernel.org>
> Subject: [EXT] Re: [cfe-dev] Disable certain llvm optimizations at clang
> frontend
>
> Just to be more specific about what transformations we want to disable:
>   (1). Undo a transformation in InstCombine/InstCombineAndOrXor.cpp
>         (https://reviews.llvm.org/D72787)
>         This transformation created a new variable "var.off" for comparison but
>         using the original variable "var" later on. The kernel verifier does not
>         have a better range of "var" at its use place and this may cause
>         verification failure.
>
>         To generalize, BPF prefers the single variable is refined and used later
>         for each verification. New variable can be created and used for further
>         value range refinement, but all later usage of old variable should be
>         replaced with the new variable.
>    (2). Prevent speculative code motion
>           (https://reviews.llvm.org/D82112, https://reviews.llvm.org/D81859)
>          If the code in the original program may not execute under
> certain conditions,
>          we could like the code not to execute in the final byte code
> under the same
>          condition, regardless of whether it is safe to execute or not.
>
>     I guess we could have two attributes here:
>        - "refine-value-range-with-original-var" (false by default, true for BPF)
>        - "no-speculative-code-motion" (false by default, true for BPF)

Looking at this, I'm worried that there's a bigger disconnect between the way LLVM reasons about IR, vs. what the BPF verifier can actually handle.  It isn't reasonable to blindly disable code motion; that's chasing after the symptoms of the problem, not solving the underlying issue.

If I understand correctly, the underlying issue is that BPF has a notion of a "CFG guard": you can have a condition and a branch, and instructions inside the region guarded by that branch have different rules from instructions outside that region, based on that condition.  Both clang and LLVM optimizations are completely unaware of this.  Currently, you're working around the problem in various ways, though source-code hacks and pattern-matching hacks.  But still, nothing is really aware this is happening.

I'm not sure exactly what the solution looks like here, but a " no-speculative-code-motion" attribute is not heading in the right direction.  If we want to actually make code generation reliable, we need to have rules in LangRef we can point to that describe what operations are legal/illegal.  And they need to be phrased in terms of the IR itself, independent of any specific transform.  This probably involves modifying the LLVM IR generated by clang in a more fundamental way than just adding new attributes.

-Eli