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

Phantom let support in Clambda #2060

Merged
merged 3 commits into from Oct 15, 2018

Conversation

Projects
None yet
3 participants
@mshinwell
Copy link
Contributor

commented Sep 24, 2018

This patch enables the Clambda language to represent "phantom let" expressions. These have no dynamic semantics but are used for the emission of debugging information. Typically, when a value is optimised out by Flambda, a phantom let binding will be left behind to ultimately enable visibility of such value in the debugger. Fairly complicated values can be represented in this way thanks to the DWARF constructs involving "implicit pointers", which enable heap-allocated structures to be reconstituted in the memory space of the debugger at runtime, even though they have been optimised out from the code running on the target.

@chambart or @lthls , perhaps one of you could look at this.

@mshinwell mshinwell added this to the 4.08 milestone Sep 24, 2018

@mshinwell mshinwell requested a review from chambart Sep 24, 2018

@mshinwell

This comment has been minimized.

Copy link
Contributor Author

commented Sep 24, 2018

I should add: future patches will deal with the setting of Clflags.debug_full and also the generation of those "phantom defining expression" cases that currently may appear to be unused.

@mshinwell mshinwell force-pushed the mshinwell:clambda_phantom_let2 branch 2 times, most recently from 9d906c1 to ce0299e Sep 26, 2018

@lthls

lthls approved these changes Sep 27, 2018

Copy link
Contributor

left a comment

I have reviewed this pull request. It introduces a bit of infrastructure for generating more precise debugging information, and doesn't otherwise affect normal code generation.

A small question for @mshinwell: I believe that the phantom lets introduced in un_anf (when the new debug_full flag is enabled) bind mostly variables that were created in the middle-end. Is it relevant to generate debugging information for such variables ? I expect later pull requests to refine the generation of these phantom constructions anyway, but maybe it would already make sense to restrict the phantom let generation to variables with an actual provenance.

@mshinwell

This comment has been minimized.

Copy link
Contributor Author

commented Sep 27, 2018

I'm going to have to think about your question some more, but I'm not sure that needs to delay the merge. We're going to have to refine the behaviour here anyway as we see how things pan out in practice. I'm suspecting that we might end up with phantom lets with provenance that depend on phantom lets without provenance---in which case we need to be careful what we delete.

@mshinwell mshinwell force-pushed the mshinwell:clambda_phantom_let2 branch 2 times, most recently from 7814c81 to 403ef93 Sep 28, 2018

@damiendoligez
Copy link
Member

left a comment

Approved based on @lthls's review.

@mshinwell mshinwell force-pushed the mshinwell:clambda_phantom_let2 branch from 403ef93 to ba3abca Oct 15, 2018

@mshinwell mshinwell merged commit 298ffe3 into ocaml:trunk Oct 15, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

damiendoligez added a commit to damiendoligez/ocaml that referenced this pull request Nov 5, 2018

fdagnat added a commit to fdagnat/ocaml that referenced this pull request May 21, 2019

Remove duplicated entry
entry ocaml#2060 was listed tow times

@fdagnat fdagnat referenced this pull request May 21, 2019

Merged

Remove duplicated entry #8686

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.