Skip to content

[SYCL] Fix crash when kernel argument is a multi-dimensional array. #2341

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 6 commits into from
Aug 21, 2020

Conversation

elizabethandrews
Copy link
Contributor

This patch fixes crash due to incorrect InitializedEntity for
multi-dimensional arrays. When generating the InitializedEntity
for an element, it is necessary to descend the array. For example,
the initialized entity for s.array[x][y][z] is constructed using
initialized entities for s.array[x][y], s.array[x] and s.array.
Prior to this patch, the 'descending' was not done.

Patch by: Rajiv Deodhar and Elizabeth Andrews

Signed-off-by: Elizabeth Andrews [email protected]

This patch fixes crash due to incorrect InitializedEntity for
multi-dimensional arrays. When generating the InitializedEntity
for an element, it is necessary to descend the array. For example,
the initialized entity for s.array[x][y][z] is constructed using
initialized entities for s.array[x][y], s.array[x] and s.array.
Prior to this patch, the 'descending' was not done.

Patch by: Rajiv Deodhar and Elizabeth Andrews

Signed-off-by: Elizabeth Andrews <[email protected]>
@elizabethandrews elizabethandrews changed the title [SYCL] Fix crash when kernel argument is a multi-dimensional array. [Do not commit][SYCL] Fix crash when kernel argument is a multi-dimensional array. Aug 19, 2020
from MemberExprBases. Also fixes a mistake with offset calculation
for integration headers generated. Adds lit tests.

Patch by: Rajiv Deodhar and Elizabeth Andrews

Signed-off-by: Elizabeth Andrews <[email protected]>
@elizabethandrews elizabethandrews requested a review from a team as a code owner August 20, 2020 04:19
@elizabethandrews elizabethandrews changed the title [Do not commit][SYCL] Fix crash when kernel argument is a multi-dimensional array. [SYCL] Fix crash when kernel argument is a multi-dimensional array. Aug 20, 2020
@v-klochkov
Copy link
Contributor

/summary:run

Copy link
Contributor

@Fznamznon Fznamznon left a comment

Choose a reason for hiding this comment

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

Looks very complicated and confusing.

Copy link
Contributor

@erichkeane erichkeane left a comment

Choose a reason for hiding this comment

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

I'll leave it to @Fznamznon to finish the review, but this is a move in the right direction.

Copy link
Contributor Author

@elizabethandrews elizabethandrews left a comment

Choose a reason for hiding this comment

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

Thanks for the review everyone! I will upload a new patch with the review comments.

@elizabethandrews
Copy link
Contributor Author

Does anyone know why the tests aren't running? @bader

@bader
Copy link
Contributor

bader commented Aug 20, 2020

I suppose CI is busy with pre-commits for other PRs. Did you check the Buildbot queue?

@elizabethandrews
Copy link
Contributor Author

I suppose CI is busy with pre-commits for other PRs. Did you check the Buildbot queue?

How do I do that?

@DoyleLi
Copy link
Contributor

DoyleLi commented Aug 20, 2020

I suppose CI is busy with pre-commits for other PRs. Did you check the Buildbot queue?

How do I do that?

Hi, I find the root cause for not launching CI checks is the github didn't send out webhook event for this commit in the PR. Should be github sever issue. It can be launched if someone approve the change or new commit pushed in the PR.

@elizabethandrews
Copy link
Contributor Author

I suppose CI is busy with pre-commits for other PRs. Did you check the Buildbot queue?

How do I do that?

Hi, I find the root cause for not launching CI checks is the github didn't send out webhook event for this commit in the PR. Should be github sever issue. It can be launched if someone approve the change or new commit pushed in the PR.

Thanks for the information! I will be pushing a new commit. So hopefully that will trigger it.

@Fznamznon
Copy link
Contributor

Please resolve conflicts.

Added a few more comments, renamed variables, etc

Signed-off-by: Elizabeth Andrews <[email protected]>
erichkeane
erichkeane previously approved these changes Aug 20, 2020
Signed-off-by: Elizabeth Andrews <[email protected]>
erichkeane
erichkeane previously approved these changes Aug 20, 2020
v-klochkov
v-klochkov previously approved these changes Aug 20, 2020
Copy link
Contributor

@v-klochkov v-klochkov left a comment

Choose a reason for hiding this comment

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

I don't see anything wrong in this patch.
Couple places still remain not clear to me, thus I rely on review/approvals from FE experts @erichkeane and @Fznamznon

Fznamznon
Fznamznon previously approved these changes Aug 20, 2020
Copy link
Contributor

@Fznamznon Fznamznon left a comment

Choose a reason for hiding this comment

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

Just a couple of code-style nits. Otherwise LGTM

premanandrao
premanandrao previously approved these changes Aug 20, 2020
Renamed a variable
Simplified MemberExprBasesIdx calculation removing +1/-1
Changed type of Index to uint64_t

Signed-off-by: Elizabeth Andrews <[email protected]>
Copy link
Contributor

@keryell keryell left a comment

Choose a reason for hiding this comment

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

It is too easy to get wrong because of symmetry mirages...

// Each dimension has an ArraySubscriptExpression (maintains index)
// in MemberExprBases. For example, if we are currently handling element
// a[0][0][1], the top of stack entries are ArraySubscriptExpressions for
// indices 0,0 and 1, with 1 on top.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do not use same numbers, it is too confusing.
We had this issue in the spec...

// We need to find the type of the element for which we are generating the
// InitListExpr. For example, for a multi-dimensional array say a[2][3][2],
// the types for InitListExpr of the array and its 'sub-arrays' are -
// int [2][3][2], int [3][2] and int [2]. This loop is used to obtain this
Copy link
Contributor

Choose a reason for hiding this comment

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

Do not use same numbers, it is too confusing.
I found using prime number is even better in the case of concrete computations.
For example here int [2] is not instantaneously obvious which [2] we are talking about.
Use for example int [5][3][2]

@@ -46,9 +74,21 @@ __attribute__((sycl_kernel)) void a_kernel(const Func &kernelFunc) {
int main() {

int a[5];
int b[2][3];
int c[2][3][2];
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
int c[2][3][2];
int c[2][3][5];


a_kernel<class kernel_D>(
[=]() {
int local = c[0][1][1];
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
int local = c[0][1][1];
int local = c[0][1][2];

@bader
Copy link
Contributor

bader commented Aug 21, 2020

@elizabethandrews, please, address comments from @keryell in a separate PR. These comments do not seem to be blocking, so I'll merge.

@bader bader merged commit 36f6ab6 into intel:sycl Aug 21, 2020
jsji pushed a commit that referenced this pull request Feb 15, 2024
OpenCL and NonSemantic DebugInfo specifications are flexible in terms of allowing any debug information be replaced with DebugInfoNone, so various of SPIR-V producers follow that and generate it for base types of several debug instructions, leaving SPIR-V consumers to handle this. By default the translator replaces missing debug info with tag: null, which is in most cases correct. Yet, there are situations, where it's not allowed by both LLVM and DWARF, for example for DW_TAG_array_type DWARF spec sets, that DW_AT_type attribute is mandatory. For such cases new transNonNullDebugType wrapper function was added to the translator, generating "DIBasicType(tag: DW_TAG_unspecified_type, name: "SPIRV unknown type")" where DebugInfoNone was used as the type. This function doesn't replace all calls to transDebugInst<DIType> as there are cases, where we can generate null type, for example DWARF doesn't require it for DW_TAG_typedef, hence I'm not changing translation flow in this case. Additionally to this, while DWARF requires type attribute for DW_TAG_pointer_type, LLVM does not, hence I'm not changing translation flow in this case as well.

Signed-off-by: Sidorov, Dmitry <[email protected]>

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@ec023805a0ce26f
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.

9 participants