Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does option -g affect optimization passes? #5426

Closed
vicuna opened this issue Dec 14, 2011 · 9 comments
Closed

How does option -g affect optimization passes? #5426

vicuna opened this issue Dec 14, 2011 · 9 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Dec 14, 2011

Original bug ID: 5426
Reporter: @gasche
Assigned to: meyer
Status: closed (set by meyer on 2011-12-22T19:07:20Z)
Resolution: fixed
Priority: low
Severity: text
Category: ~DO NOT USE (was: OCaml general)
Related to: #5313
Monitored by: tgazagna @ygrek

Bug description

In entry #5313, ygrek noticed that some temporary bug disabled a specific optimization when debugging option -g is passed to the compiler. While the bug was fixed, the question still stand: how does -g affect the compiler optimizations?

@vicuna
Copy link
Author

vicuna commented Dec 17, 2011

Comment author: meyer

The following optimisations are definitely not performed in the bytecode
compiler when -g flag is used:

  • let bindings like:
    let a = b in a

    will not be locally transformed to:

    b

  • Constructs like:
    let a = b in
    let c = <...> in

    the binding of a to b will not be transformed to:

    let c = <...> in

  • Constructs like
    let a = in

    will not be transformed to:

  • The compiler will not perform various optimisations of references like here:
    let x = ref 0 in
    for i = 1 to 10 do
    x := !x + i
    done
    and will not de-heapify the reference cell and use substitution on
    stack instead. This was noted by ygrek in the parent Mantis PR.

@vicuna
Copy link
Author

vicuna commented Dec 17, 2011

Comment author: meyer

ygrek are you happy with this explanation?

Thanks,
Wojciech

@vicuna
Copy link
Author

vicuna commented Dec 17, 2011

Comment author: @ygrek

Thanks for your investigation and sorry for not communicating my initial feature wish more directly. What I really want is the compiler option to add debugging symbols but not influence code generation in any way (be it -g or some new option).
Also, when I looked through the code I remember seeing -g generating new code path for each potential out of bounds access instead of calling common code (presumably for easier debugging) (thus increasing code size).

@vicuna
Copy link
Author

vicuna commented Dec 17, 2011

Comment author: meyer

Hello,

First I would need to ask the exact use case or the problem you are facing when the optimisations are not performed. I am sure that these optimisations are not performed for some reason - possibly because then you would not be able to inspect the symbols optimised out in the debugger, however I am not certain if the reason is not rooted deeper than just providing context for debugging.

Maybe in your use case we could think about other possibility.

Wojciech

@vicuna
Copy link
Author

vicuna commented Dec 17, 2011

Comment author: @ygrek

possibly because then you would not be able to inspect the symbols optimised out in the debugger

I am not using debugger to inspect values at runtime but rather using debugging info to profile program and increase speed. In this case any disabled optimization plays against me and running without debug info makes impossible to profile. I do not have any specific code example now. AFAIK enabling debug info doesn't disable optimization in many compilers (e.g. for c/c++) and it is expected that some values are optimized out etc. Also I understand the need for disabling some optimizations to simplify debugging. But I believe it should be a choice of user on two independent axis : debug info and optimizations.

@vicuna
Copy link
Author

vicuna commented Dec 18, 2011

Comment author: @xavierleroy

Wojciech's analysis is correct as far as I can remember.

Many compilers (other than gcc) turn optimizations off when compiling in debug mode. In the case of OCaml, the optimizations in bytecomp/simplif.ml are turned off so that the user of ocamldebug can inspect all variables as they appear in the source program.

I agree with ygrek that "ocamlopt -g" should not turn optimizations off in bytecomp/simplif.ml, since we don't have a need to inspect local variables as with ocamldebug. That should be a simple patch. For "ocamlc -g", it might be good enough to keep turning optimizations off as we do today.

@vicuna
Copy link
Author

vicuna commented Dec 18, 2011

Comment author: meyer

Thanks. Now I noticed that most (all of them?) of this optimisations are disabled only in bytecode compiler - I need to read the code more thouroughly once again to confirm. So in short ocamlopt should behave correctly with respect to -g (need to check it again). This functionality came with the previous fix I mentioned in the parent PR. I updated the toplevel note.

@vicuna
Copy link
Author

vicuna commented Dec 22, 2011

Comment author: meyer

I've improved a bit handling of -g flag in ocamlopt. So now no optimisations should be disabled in ocamlopt when -g flag is present. The fix will be for the #5313 issue (already closed). Closing this issue as it's been validated by Xavier L.

@vicuna
Copy link
Author

vicuna commented Dec 22, 2011

Comment author: meyer

Reopened wrong issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant