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

The magic numbers from the nextBaseAddress are incorrectly compared with constant values #1405

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

AlexDemydenko
Copy link
Contributor

constant values. They are usually simplified as unequal values.

Copy link

google-cla bot commented Oct 2, 2024

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@rjodinchr
Copy link
Collaborator

Could you provide a small test exercising the issue?

@AlexDemydenko
Copy link
Contributor Author

AlexDemydenko commented Oct 2, 2024

CL code

kernel void test_kernel(global float *src, global long *dst)
{
    uint tid = get_global_id(0);
    dst[tid] = (long)(src != 0);
}

SPIRV below is missing:

................
         %40 = OpPtrNotEqual %bool %30 %38
         %43 = OpSelect %ulong %40 %ulong_1 %ulong_0
.............

The pass just will remove it, because the src can't be equal to nullptr.

@rjodinchr
Copy link
Collaborator

Can you add a unit test with that to the PR please?

@AlexDemydenko AlexDemydenko force-pushed the GFXSW-22729 branch 2 times, most recently from 687dbba to 17c7305 Compare October 3, 2024 11:40
@rjodinchr
Copy link
Collaborator

Can you sign the CLA please? We won't be able to merge this PR without it. Thanks

@AlexDemydenko
Copy link
Contributor Author

Could you please merge this PR?

@rjodinchr
Copy link
Collaborator

Your branch is 53 commits behind google/main. Please rebase on top-of-tree in order to have it tested properly by the bots.
Thank you

constant values. They are usually simplified as unequal values.
@AlexDemydenko
Copy link
Contributor Author

done

@rjodinchr
Copy link
Collaborator

Can you explain why it is incorrect to compare the magic numbers with constant values? This is not obvious to me right now, and this pass has been designed to do exactly that. So this change is basically trying to get rid of that pass.

Maybe you just want to call clspv with --hack-logical-ptrtoint=0?

@AlexDemydenko
Copy link
Contributor Author

The LogicalPointerToIntPass generates the base-addresses for each argument in some virtual/compiler memory space.
arg1 = 0x10000000ULL
arg2 = 0x20000000ULL
arg3 = 0x30000000ULL

This is not a real address, but it is good enough to compare (==, !=) it with other generated pointers (It also has problems, but that's not what this commit about).
But it has no sense to compare generated-address to any pointer from runtime/GPU memory space.
A constant in the kernel contains a value from runtime/GPU memory space.

If you compare any generated-pointer to nullptr it will always be false in terms of logic of the LogicalPointerToIntPass, but tis is not true.

@rjodinchr
Copy link
Collaborator

Do you mean that your issue is with a comparison returning true because a constant matches the virtual address LogicalPointerToIntPass has generated for an object (while it should return false)?

@AlexDemydenko
Copy link
Contributor Author

It is return true because a constant NOT matches the virtual address LogicalPointerToIntPass has generated.
dst[tid] = (long)(src != 0);
as result replace OpPtrNotEqual instruction to a "True" value.

@rjodinchr
Copy link
Collaborator

Is this about the OpenCL-CTS test_api null_buffer_arg?
If it is, note that you definitively need physical_addressing enabled to pass conformance.

@AlexDemydenko
Copy link
Contributor Author

Yes, this is about this test. And we want to pass this test. This test is passed with this change.

@rjodinchr
Copy link
Collaborator

While this change is fixing the test on your end, I'm not sure this is the way to do it properly for clspv.
I believe this test needs physical_addressing enabled to pass properly.

@AlexDemydenko
Copy link
Contributor Author

This pass has to handle Logical pointers and it doesn't require the physical-storage-buffers flag. What is "the way" to solve this issue at your opinion?

Before I will get response from OCL team. I can try to do another solution, but I need to understand what are you thinking about this?

@rjodinchr
Copy link
Collaborator

I think that OpenCL test (test_api null_buffer_arg) requires physical-storage-buffers to pass properly with the Vulkan-Validation-Layers enabled.

You will note that we have this back and forth discussion because you are not sharing enough to let us understand what is happening on your side (you could have mentioned the OpenCL-CTS directly in your PR for example).

What I don't understand right now is how you have set up Vulkan so that OpPtrNotEqual works without physical-storage-buffers.

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