Skip to content

Supporting list of lists, list of tuples and tuples with lists #952

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

Merged
merged 10 commits into from
Aug 13, 2022

Conversation

czgdp1807
Copy link
Collaborator

No description provided.

@certik
Copy link
Contributor

certik commented Aug 10, 2022

Excellent!

@namannimmo10
Copy link
Collaborator

Thanks @czgdp1807!

@czgdp1807 czgdp1807 marked this pull request as ready for review August 13, 2022 14:36
@czgdp1807 czgdp1807 requested a review from certik August 13, 2022 14:36
@czgdp1807
Copy link
Collaborator Author

czgdp1807 commented Aug 13, 2022

@certik This is ready for review. I have cleaned up the git history so you can review each commit individually.

@czgdp1807 czgdp1807 mentioned this pull request Aug 13, 2022
7 tasks
Copy link
Contributor

@certik certik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing. That's super exciting that all these features now work.

Everything looks good. I left one question below. If this does not slow down anything that is already in master, then it can be merged.

builder->CreateBr(loophead);

// end
llvm_utils->start_new_block(loopend);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this slow anything down in the already existing list (or any other) functionality in master? For example in our current benchmarks for lists? Or is this only used for new features implemented in this PR, but does not affect any feature already in master.

Copy link
Collaborator Author

@czgdp1807 czgdp1807 Aug 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code path will only be taken for nesting of types inside lists (which is a new feature not supported earlier). For list[f64], list[i32], etc (i.e., a list with intrinsic element type, the code path in main will be taken). So, theoretically no change in benchmarks should happen.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you say "code path", you mean code path at compile time? If so, then this is good.

If you mean "runtime", then that must mean there might be some "if statement" being executed at runtime, and we don't want that.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you say "code path", you mean code path at compile time?

Yes code path at compile time.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the benchmarks for my linux system in #857 (comment). I don't see any change with list05 (the branch of this PR).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated #857 (comment) with results from my macbook, this and main branch give no difference for me.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bottomline - This and main branch give same results on both of my systems. So, theoretically and practically from my perspective this PR wouldn't slow down anything for features already existing in main. @certik Do you want to merge it?

@certik certik merged commit 35dffd6 into lcompilers:main Aug 13, 2022
@certik
Copy link
Contributor

certik commented Aug 13, 2022

Yes, for sure. Thank you so much for this. Very exciting.

@czgdp1807 czgdp1807 deleted the list05 branch August 14, 2022 04:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants