[llvm-bugs] [Bug 35950] opt is defunct when code built without optimizations

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Jan 15 23:57:42 PST 2018


https://bugs.llvm.org/show_bug.cgi?id=35950

Jiri Slaby <jirislaby at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
                 CC|                            |c.cadar at imperial.ac.uk,
                   |                            |dan at su-root.co.uk
             Status|RESOLVED                    |REOPENED

--- Comment #2 from Jiri Slaby <jirislaby at gmail.com> ---
(In reply to David Blaikie from comment #1)
> This behavior is intentional.
> 
> -O0 IR carries with it that contract that it should not be optimized - so
> opt satisfies that request by running the optimization passes, but they all
> do nothing to modify -O0 IR.
> 
> This is important when preserving the semantic request of -O0 in IR that is
> merged from multiple other IR files, some of which may be compiled with -O0
> and some with optimizations enabled.

Hmm, that is not nice and even incorrect. If somebody wants such behaviour,
introduce a new compiler option and do not abuse -O0. Or introduce an option to
disable this new behaviour. -O0 is even implicit -- users do not actually
"disable" optimizations, they just do not enable any. And even if they do -O0,
that does not necessarily mean they do not want to optimize later.

The problem with the current approach is that many users do not optimize during
compilation, but optimize the code in runtime (via PassManagers) and multiple
times in different ways. Klee is one of the examples. And given this behaviour
changed in clang 5, klee is unable to optimize, so this is clearly a
regression.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180116/2dbaf4bc/attachment.html>


More information about the llvm-bugs mailing list