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

[Hal Finkel via cfe-dev]

On 6/19/20 3:08 PM, Eli Friedman wrote:
> (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


+1 to all of this. We need to have well-defined semantics at the IR level.

A lot of these problems seem to come from the fact that the verifier is 
verifying each value at the point of calculation instead of at the point 
each value contributes to an operation with side effects. If the 
verifier cannot be improved in this regard, it seems like you need to 
represent these side effects at the IR level, and perhaps other aspects 
of the state of the verifier. For example, we might essentially add the 
inaccessiblememonly attribute to condition calculations and other 
relevant intrinsics. Is the verifier worried about all arithmetic 
somehow, or only pointer arithmetic (from GEPs)?

  -Hal


-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory