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

[Johannes Doerfert via cfe-dev]

General comment after reading most of the thread:


I guess there are two opposing ways to approach this:

     1) try to "preserve" the restrictions assuming the input is valid, or

     2) try to enforce the restrictions at the end of the pipeline, 
i.a., legalize the IR.

I would strongly recommend 2) if at all possible.


One way would be:

Run normally, try to legalize with approximation of the requirements.

If the legalization fails report it to the user.

Maybe fail and force the user to lower optimization level, or 
automatically do so.


The thing is, any form of IR annotation that is semantic bearing needs 
to be known to a lot of places and a lot of places do similar things.

Disabling some concept like "code motion" is not only affecting various 
places but also a grey area wrt. the definition of "code motion".

This will be the same for any "transformation", I expect at least.


Cheers,

   Johannes



On 6/19/20 1:50 AM, Y Song via cfe-dev wrote:
> Hi,
>
> This is to seek some advice on how to disable certain llvm
> optimizations when compiled with clang for BPF backend. For example,
> we want to disable two optimizations, instcombine and simplifyCFG. I
> would like to get some advice about what is the best way to do it.
>
> Some Background on Why We want to do this
> ===================================
>
> Any BPF code needs to go through a kernel verifier
>     https://github.com/torvalds/linux/blob/master/kernel/bpf/verifier.c
> before it can be executed in the kernel. verifier tries to ensure the safety
> of the program, no illegal memory access, etc. In certain cases, clang
> generated optimized codes make verification very hard, see pending
> commits with another approach focused on BPF backend and some core
> optimizations.
>    https://reviews.llvm.org/D72787
>    https://reviews.llvm.org/D82112
>    https://reviews.llvm.org/D81859
> To workaround the issue, people have to write inline asm or tweak
> their program in a very user-unfriendly way to disable certain
> transformations, in particular, instcombine and simplifyCFG.
>
> Alternative Method in clang Frontend
> ============================
>
> The above approach tried to disable/undo/influence specific
> optimizations. Another approach is to disable instcombine and
> simplifyCFG during compilation process. This is a little bit heavy
> weight. But it may still be fine as this will ease the pain for
> development. For most customers, a little performance loss vs.
> development gain probably will be fine.
>
> How to disable instcombine/simplifyCFG in clang frontends? It looks
> like function attributes and insn metadatas are used to influence
> optimizations.
> The following approach might work, I think:
>     BPF backend may add the following two attributes to all functions:
>     "disable-instcombine" = "true"
>     "disable-simplifyCFG" = "true"
> And during instcombine and simplifyCFG, the above function attribute will
> be checked, it is true, the pass will be skipped.
>
> Do you think the above method could work? Any alternative suggestions
> are also appreciated.
>
> Thanks!
>
> Yonghong
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200624/f117847e/attachment.html>