[SYCL]Remove warning about SYCL_EXTERNAL with pointers

[srividya-sundaram]

Raw pointers for SYCL_EXTERNAL are prohibited without generic address space. Generic address space doesn't exist in 1.2.1 and is optional in 2020. Our implementation isn't spec compliant to 1.2.1 because we use generic address space (among other).
This diagnostic has no practical value to users. We aren't warning about something which has any impact for our implementation based on generic address space.

[Fznamznon]

I don't have strong preference here, but this diagnostic was spec-defined behavior even though our implementation of address spaces is not SYCL 1.2.1 compliant. So, it would be great to hear feedback from @mkinsner and @rolandschulz here.

[srividya-sundaram]

@Fznamznon This change was made based on @rolandschulz's input. I will share his comment below.
@rolandschulz Please feel free to provide your feedback on this change. Thanks!

Raw pointers for SYCL_EXTERNAL are prohibited without generic address space. Generic address space doesn't exist in 1.2.1 and is optional in 2020. Our implementation isn't spec compliant to 1.2.1 because we use generic address space (among other).

It seems useless to warn about a detail (SYCL_EXTERNAL with pointers) if the base functionality (pointers using inference rules vs generic address space) isn't implemented spec compliant and the reason for the spec rule is based on the assumption of the implementation.

And this diagnostic has no practical value to users. We aren't warning about something which has any impact for our implementation based on generic address space. And it isn't useful for portability to other implementation. Because this is only a portability concern if the other implementation doesn't support generic address space.

But in that case a useful warning needs to warn for any functionality which isn't supported without generic address space (using the SYCL inference rules instead). This is among other SYCL_EXTERNAL with raw pointer, assignment of raw pointers which can't be inferred (e.g. in conditionals), function ptrs with raw pointers. That warning would allow a user to target implementation which don't support generic address space. And as part of that warning its useful to warn for SYCL_EXTERNAL. But just warning for SYCL_EXTERNAL without also warning for all other features which depend on generic address space is useless.

[rolandschulz]

The PR message contains one of my sentences:

This diagnostic has no practical value to users.

But it doesn't contain the other part:

[] a useful warning needs to warn for any functionality which isn't supported without generic address space

We might want to create a new issue to add such a useful warning and partially revert this commit and make it a part of such a new optional warning. I'm not sure whether users need that or would just use a different SYCL implementation without generic address space if they need to get diagnostic regarding features not available without generic address space.

Either way I think we want to use this commit for now.

[premanandrao]

LGTM

[srividya-sundaram]

I don't see any test failures reported in buildbot/Lit_With_Cuda.
But I do see the following time out error:

command timed out: 1200 seconds without output running [b'python3', b'llvm_ci/intel/worker/tools/build.py', b'-n', b'3968', b'-b', b'pull/2722/head', b'-r', b'2722', b'-p', b'sycl', b'-s', b'configuration', b'-t', b'Release', b'--cuda', b'-P', b'intel/llvm', b'-m', b'Lit_With_Cuda', b'-e', b'c4324818656e725b3f4b538a0ba7d06e9f985917', b'-U', b'http://ci.llvm.intel.com:8010/#/builders/37/builds/3968'], attempting to kill
process killed by signal 9
program finished with exit code -1

I tried retriggering the build a couple of times but still get the above failure.
@bader @romanovvlad Any idea if this is a known infrastructure issue?

Update: The Cuda buildbot has passed this time.

[bader]

I don't see any test failures reported in buildbot/Lit_With_Cuda.
But I do see the following time out error:

command timed out: 1200 seconds without output running [b'python3', b'llvm_ci/intel/worker/tools/build.py', b'-n', b'3968', b'-b', b'pull/2722/head', b'-r', b'2722', b'-p', b'sycl', b'-s', b'configuration', b'-t', b'Release', b'--cuda', b'-P', b'intel/llvm', b'-m', b'Lit_With_Cuda', b'-e', b'c4324818656e725b3f4b538a0ba7d06e9f985917', b'-U', b'http://ci.llvm.intel.com:8010/#/builders/37/builds/3968'], attempting to kill
process killed by signal 9
program finished with exit code -1

I tried retriggering the build a couple of times but still get the above failure.
@bader @romanovvlad Any idea if this is a known infrastructure issue?

Update: The Cuda buildbot has passed this time.

@dm-vodopyanov and @alexbatashev were looking into this issue in the past. It's a known issue, but it doesn't look like "infrastructure" issue.

[srividya-sundaram]

@bader Thanks for clarifying that it is not an "infrastructure" issue. IIRC, I saw this issue in one other PR at least.
@dm-vodopyanov , @alexbatashev Can you please share if this issue is fixed?

[alexbatashev]

@bader Thanks for clarifying that it is not an "infrastructure" issue. IIRC, I saw this issue in one other PR at least.
@dm-vodopyanov , @alexbatashev Can you please share if this issue is fixed?

At the moment, the root cause of this issue is unknown.