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

ocaml{c,opt}: Provide command-line options to stop compilation after any stage #6102

Closed
vicuna opened this issue Jul 29, 2013 · 12 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Jul 29, 2013

Original bug ID: 6102
Reporter: @gasche
Status: acknowledged (set by @damiendoligez on 2013-08-28T09:25:51Z)
Resolution: open
Priority: low
Severity: feature
Category: compiler driver
Tags: patch, junior_job
Related to: #3861 #5548
Monitored by: @bobzhang @hcarty

Bug description

It would be occasionally useful to stop compilation just after parsing, or just after type-checking but without outputting anything unless there are errors, etc. A regular way to support this would be to allow stopping after any phase of the compiler (or at least: parsing, typing, lambda and cmm).

Some use cases:

(1) ocamlfind does not provide an "ocamlfind camlp4 -package foo.syntax ..." option allowing to easily preprocess source files, as would be needed to solve #5548 (ocamlbuild -use-ocamlfind with a .pp.ml target). A workaround would be to use "ocamlfind ocamlc -dsource -package foo.syntax ..." (even better, -dsource would also take into account ppx rewriters), but that would fail if the source doesn't type-check, as there is currently no way to stop the compiler between parsing and type-checking.

(2) currently option -i both print interface information and stops the compiler after type-checking; if we had a proper option to stop after type-checking, we wouldn't need to mix those two different things, and could provide a -dintf command to satisfy the oddly phrase #3861

(3) when debugging bad behaviors of the compiler (exponential time consuption, stack overflow, etc.), it would be fairly useful to be able to stop at the phase just before the thing blows up.

File attachments

@vicuna
Copy link
Author

vicuna commented Jul 31, 2013

Comment author: @lpw25

Just a note to point out that Jon has attached a patch for this request

@vicuna
Copy link
Author

vicuna commented Jul 31, 2013

Comment author: @gasche

Thanks for the note; I hadn't seen the patch indeed. And thanks Jon for the patch!

I have doubts about "exit 0" as an implementation technique for quitting early. Both in the frontend and the backend, there are resources to collect (for example in the frontend, the temporary preprocessing file, if any, must be removed after parsing).

It may work better to raise one specific exception (Exit should work if it isn't raised by the incumbent code, or a specifically defined exception) and handle it differently than the others. Another option (in the frontend case only, backend requires a bit more work, see below), which I think should be preferred because it is more clearly correct, would be to redefine the piping (++) used as:

let (++) x f = match x with None -> () | Some v -> Some (f v)

and then have "quit_if" inject a None value (using a different can-fail piping operator). This works because those function piping always return a unit in the end, so there is no intermediate value to collect before quitting (remark: we should avoid using GADT hammers at this point in the compiler code, but it shouldn't be necessary here).

The backend is unfortunately a bit more delicate: both compile_genfuns and the later Cmm.reference_symbols may print cmm information which should be run before quit_after_cmm fires, so I guess some heavier reworking of the code would be required -- I initially hadn't planned for that when mentioning quitting after cmm, sorry. You should feel free to leave this part out of a patch: handling the frontend part is already very useful. If you manage to do a reworking that preserves the printing semantics without hurting readability, you should submit that as a separate patch to ease review.

@vicuna
Copy link
Author

vicuna commented Feb 20, 2019

Comment author: @gasche

4.08 has a new "-stop-after " option that partially implements this: the only two supported passes are 'parsing' and 'typing', but support for more is welcome.

@dsmith47
Copy link
Contributor

dsmith47 commented Apr 5, 2019

Was interested in trying to add support for -stop-after lambda to build an understanding for the compiler phases. Is this still a relevant feature?

@gasche
Copy link
Member

gasche commented Apr 5, 2019

I think this would be fine (you probably want to look at driver/compile_common and driver/{compile,optcompile}.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 15, 2020
@gasche gasche removed the Stale label Jun 17, 2020
@gasche gasche reopened this Jun 17, 2020
@nojb
Copy link
Contributor

nojb commented Sep 8, 2020

Just for info, having a "stop-after-typing" flag that also produced as a side-effect .cmi, .cmt and .cmti files would be useful for dune, see ocaml/dune#3758

cc @rgrinberg @jberdine

@gasche
Copy link
Member

gasche commented Sep 9, 2020

I think it would be fine to change the behavior of -stop-after typing to produce those files (for the latter, when -bin-annot is passed I guess), with the rationale that for passes that produce a target, -stop-after runs after this target. Or we could add a new pass name for just the target production, for example -stop-after-typing-output.

(cc @gretay-js who thought about -stop-after usage as well.)

@rgrinberg
Copy link
Member

rgrinberg commented Sep 9, 2020 via email

@gretay-js
Copy link
Contributor

@rgrinberg There is PR #9003 for resuming compilation from emit stage. It takes as input a file that contains marshaled Linear IR.
Overall, the compilation is split into two steps, using a command thats look like this:
ocamlopt -stop-after scheduling -save-ir-after scheduling t.ml <other options>
which generates t.cmir-linear file and followed by
ocamlopt t.cmir-linear <other options>
that resumes the compilation.

For start after typing, would you need to save the IR? I wonder if .cmi/.cmt/.cmti files have all the information and also if there is any global state of compilation that would need to be saved. For saving Linear IR to a file (PR #8938), there was some global shared between passes state that needed to be carefully rearranged or saved along with the Linear IR.

By the way, start/stop after scheduling is used in ocamlfdo rules in dune ocaml/dune#2768, but I'd need to update it to the latest incarnation of PR #9003 in which we don't need "-start-from scheduling" any more. Instead, the compiler detects the stage to start from based on the input file format/extension. It's somewhat similar to what happens when the input is a parse tree.

@gretay-js
Copy link
Contributor

I think it would be fine to change the behavior of -stop-after typing to produce those files (for the latter, when -bit-annot is passed I guess), with the rationale that for passes that produce a target, -stop-after runs after this target. Or we could add a new pass name for just the target production, for example -stop-after-typing-output.

(cc @gretay-js who thought about -stop-after usage as well.)

No change is needed: -stop-after typing already produces these files.

@github-actions
Copy link

github-actions bot commented Aug 3, 2022

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Aug 3, 2022
@github-actions github-actions bot closed this as completed Oct 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants