Skip to content

Create "char buffer[...]" for "i8[...]" typed arrays #1346

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 7 commits into from
Dec 5, 2022

Conversation

czgdp1807
Copy link
Collaborator

@certik Note that avoiding descriptors is impossible (as far as I can think) for "i8[:]" annotation, because we need to store lower and upper bounds. Hence I implemented this feature only for "i8[some_compile_time_dimension]".

@czgdp1807 czgdp1807 marked this pull request as ready for review December 2, 2022 16:59
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.

I only reviewed quickly, it seems good to me. I have not reviewed every detail, but if it looks good to you as well, then go ahead and merge. We can fix it later if something doesn't work.

@czgdp1807 czgdp1807 enabled auto-merge December 5, 2022 05:02
@czgdp1807 czgdp1807 merged commit 81cf7de into lcompilers:main Dec 5, 2022
@czgdp1807 czgdp1807 deleted the i8_array branch December 5, 2022 06:23
array = CreateLoad(array);
}
bool is_data_only = is_argument && !ASRUtils::is_dimension_empty(m_dims, n_dims);
is_data_only = is_data_only || is_i8_array;
Copy link
Contributor

Choose a reason for hiding this comment

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

In here I am not sure we should special case i8. I think there is nothing special about i8, we should have exactly the same handling for all integer (and real and complex) arrays.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Well, I guess the requirement was to create data only array for i8 if its a BindC. See #1333

if( !force_declare ) {
force_declare_name = std::string(v.m_name);
}
sub = "char " + force_declare_name + dims;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not using int8_t ? It seems that's cleaner and consistent with i16, i32, i64, etc.

Copy link
Collaborator Author

@czgdp1807 czgdp1807 Dec 5, 2022

Choose a reason for hiding this comment

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

I think in the issue it was mentioned to create char buffer[64] for buffer: i8[64].

@certik
Copy link
Contributor

certik commented Dec 5, 2022

I reviewed it commit by commit, it's clean, but I don't like the special casing for i8.

If we can't determine this robustly ourselves, we might need to annotate the array in the source code, perhaps change i8[64] to NoDescriptor[i8[64]] or something like that, then set this in ASR.

I know we are struggling with exactly this issue in LFortran also at this very moment, when to use a descriptor and when not. This just adds to the complexity of the "ad-hoc" decision in the backend, and if the decision is this complex, then I think it should be part of ASR itself and the optimizer will choose, or even the frontend (initially).

@czgdp1807
Copy link
Collaborator Author

czgdp1807 commented Dec 5, 2022

I reviewed it commit by commit, it's clean, but I don't like the special casing for i8.

+1. I also didn't like it while implementing this. However from what I understood by reading #1333, and #1333 (comment), I thought it was needed only for i8 typed arrays.

My suggestion would be to always create data only arrays for fixed sizes and use descriptors otherwise.

@certik
Copy link
Contributor

certik commented Dec 5, 2022

See #1350 to discuss this more.

(There is nothing special about i8.)

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.

2 participants