<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="Hack Nerd Font Mono">General comment after reading
        most of the thread:</font></p>
    <p><font face="Hack Nerd Font Mono"><br>
      </font></p>
    <p><font face="Hack Nerd Font Mono">I guess there are two opposing
        ways to approach this:</font></p>
    <p><font face="Hack Nerd Font Mono">    1) try to "preserve" the
        restrictions assuming the input is valid, or</font></p>
    <p><font face="Hack Nerd Font Mono">    2) try to enforce the
        restrictions at the end of the pipeline, i.a., legalize the IR.</font></p>
    <p><font face="Hack Nerd Font Mono">I would strongly recommend 2) if
        at all possible.</font></p>
    <p><font face="Hack Nerd Font Mono"><br>
      </font></p>
    <p><font face="Hack Nerd Font Mono"> One way would be:</font></p>
    <p><font face="Hack Nerd Font Mono">Run normally, try to legalize
        with approximation of the requirements.</font></p>
    <p><font face="Hack Nerd Font Mono">If the legalization fails report
        it to the user.</font></p>
    <p><font face="Hack Nerd Font Mono"> Maybe fail and force the user
        to lower optimization level, or automatically do so.<br>
      </font></p>
    <p><font face="Hack Nerd Font Mono"><br>
      </font></p>
    <p><font face="Hack Nerd Font Mono">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.<br>
      </font></p>
    <p>Disabling some concept like "code motion" is not only affecting
      various places but also a grey area wrt. the definition of "code
      motion".</p>
    <p>This will be the same for any "transformation", I expect at
      least.</p>
    <p><br>
    </p>
    <p>Cheers,</p>
    <p>  Johannes<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 6/19/20 1:50 AM, Y Song via cfe-dev
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH3MdRWZR-Z2_SOPrcCqm6NB2gXf7jdGWsw9qkNNK5Cy_gKNKg@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">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
   <a class="moz-txt-link-freetext" href="https://github.com/torvalds/linux/blob/master/kernel/bpf/verifier.c">https://github.com/torvalds/linux/blob/master/kernel/bpf/verifier.c</a>
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.
  <a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D72787">https://reviews.llvm.org/D72787</a>
  <a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D82112">https://reviews.llvm.org/D82112</a>
  <a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D81859">https://reviews.llvm.org/D81859</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
  </body>
</html>