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

Improve sharing of values #7535

Closed
vicuna opened this issue May 18, 2017 · 5 comments · May be fixed by #8958
Closed

Improve sharing of values #7535

vicuna opened this issue May 18, 2017 · 5 comments · May be fixed by #8958

Comments

@vicuna
Copy link

vicuna commented May 18, 2017

Original bug ID: 7535
Reporter: Eugene
Status: acknowledged (set by @xavierleroy on 2017-09-30T16:09:30Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.04.1
Category: back end (clambda to assembly)

Bug description

Given following snippet of a code:

type 'a id = Id of 'a

let make (Id x) = Id x

allocation happens every time 'make' called (using flambda-enabled compiler).
Unfortunately it prevents a lot of further optimizations that could happen if it was compiled as simply

let make (Id _ as x) = x

It seems that flambda already capable of eliminating some allocations, i.e.

let make x =
let f (Id x) = Id x in
f @@ f @@ f @@ f @@ f x

allocates only one block.

@vicuna
Copy link
Author

vicuna commented May 19, 2017

Comment author: @sliquister

In this specific example, you'd be better off adding [@@unboxed] on the type definition (or using the command flag that adds it implicitely).

But it's true that sometimes, the compiler could avoid reallocating things, especially when the workaround is not expressible in the source like:

function
| [] -> assert false
| hd :: tl -> hd, tl

@github-actions
Copy link

github-actions bot commented May 8, 2020

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 8, 2020
@nojb
Copy link
Contributor

nojb commented May 8, 2020

I believe this is implemented in #8958 (but the PR seems to have stalled).

@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 Jun 16, 2021
@Octachron Octachron removed the Stale label Jun 16, 2021
@github-actions
Copy link

github-actions bot commented Jul 1, 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 Jul 1, 2022
@github-actions github-actions bot closed this as completed Aug 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants