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 Cmm code generator for "for" loops. #5346

Closed
vicuna opened this issue Aug 21, 2011 · 5 comments
Closed

Improve Cmm code generator for "for" loops. #5346

vicuna opened this issue Aug 21, 2011 · 5 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Aug 21, 2011

Original bug ID: 5346
Reporter: meurer
Status: closed (set by @mshinwell on 2016-12-07T12:57:02Z)
Resolution: not a bug
Priority: normal
Severity: tweak
Version: 3.12.1
Target version: later
Category: ~DO NOT USE (was: OCaml general)
Tags: patch
Monitored by: meyer @protz @ygrek @hcarty @alainfrisch

Bug description

The code generated by cmmgen for Ufor loops doesn't optimize in case of constant low and high expressions. This is fixed by a special case where the initial comparison can be skipped in case of constant low and high subexpressions.

In addition, this patch also reorders the generated code by moving the initial comparison out of the catch block in the general case. This may enable certain optimizations in later phases.

File attachments

@vicuna
Copy link
Author

vicuna commented Dec 16, 2011

Comment author: @protz

Hi,

First of all, thanks for the patch. Disclaimer: I'm in no way an expert of Cmm. Here are some preliminary remarks, though.

  • Your patch adds complexity for what seem to be little benefit. The test is an initial one, it's not in the loop. You're just skipping a couple instructions. Is it worth the extra complexity of your approach? Can you justify better why we should make that case harder to understand in cmmgen?
  • There are no comments in your patch, which resonates with the point above. Moreover, the current version has an id_prev identifier defined. While I fail to see why it's there in the first place (your version of the test seems both shorter and correct), I'd appreciate if you could share your thoughts on this.

Thinking about performance, even in the case of nested loops, say

for i = 0 to n; do
for j = 0 to i; do
...

then the extra test that might have been run n+1 times wouldn't be skipped since j is not a constant expression. This seems to me like a very ad-hoc optimization that adds extra complexity for close to zero benefit. I'd like to be proved wrong, though :) so please let me know why you think this optimization has to be included.

A benchmark on some real-world code may help me see better why you want this.

Cheers,

jonathan

@vicuna
Copy link
Author

vicuna commented Jul 19, 2013

Comment author: @xavierleroy

Not urgent enough for 4.01.

@vicuna
Copy link
Author

vicuna commented Nov 23, 2015

Comment author: @xavierleroy

No activity on this PR in the last 4 years. Should we keep it alive or suspend it?

@vicuna
Copy link
Author

vicuna commented Nov 23, 2015

Comment author: @mshinwell

We have some vague plans for local CPS constructs in flambda in the future; I wouldn't be surprised, having expressed these looping constructions like that, if things such as this PR just fall out in the wash.

So I would vote for closing this.

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

Comment author: @mshinwell

CPS-flambda should sort this out. Closing

@vicuna vicuna closed this as completed Dec 7, 2016
@vicuna vicuna added the bug label Mar 20, 2019
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