[SYCL] change sycl version definition to 202012

[dklochkov-emb]

Sycl language version macro is changed from 202001 to 202012L

[AlexeySachkov]

We do not support 1.2.1 mode anymore. I think that we could use the opportunity and just drop them while we are here

[maarquitos14]

+1

[dklochkov-emb]

Lets do it in a separate pull request

[AlexeySachkov]

Considering that there will be a single SYCL_LANGUAGE_VERSION per SYCL specification, I'm not sure if >= is a correct comparison going forward.

If something is only deprecated in SYCL 2020, then we should check for equality. SYCL-Next is not that far away, so I suggest that we prepare for that and use == right away. >= had more sense before the recent spec change which prompted this PR, because there could be several SYCL_LANGUAGE_VERSION values matching SYCL 2020, but it is not the case anymore.

Before any changes are made, I would like to hear feedback from @intel/llvm-reviewers-runtime as well

[maarquitos14]

+1

[AlexeySachkov]

Similar comment here, if we had any code paths which are specific to SYCL 1.2.1, we should probably use this opportunity to completely drop them, because we do not support SYCL 1.2.1 anymore

[maarquitos14]

+1

[dklochkov-emb]

Lets do it in a separate pull request

[bader]

SYCL_LANGUAGE_VERSION support has been upstreamed already, so we should land this patch to https://github.com/llvm/llvm-project/.

[elizabethandrews]

SYCL_LANGUAGE_VERSION support has been upstreamed already, so we should land this patch to https://github.com/llvm/llvm-project/.

Upstream code seems to be quite updated. It has code to define CL_SYCL_LANGUAGE_VERSION, etc. It would be nice to clean that up. The code in syclos and upstream aren't an exact match though. We don't have getSYCLVersion and I don't think we can add it there since we have different code actually calling this yet.

[AlexeySachkov]

@elizabethandrews, @bader, PR to the upstream is published here: llvm/llvm-project#114790, are you ok with merging this change to intel/llvm in advance, or should we wait for the upstream first to reduce risk of discrepancies?

[bader]

@elizabethandrews, @bader, PR to the upstream is published here: llvm/llvm-project#114790, are you ok with merging this change to intel/llvm in advance, or should we wait for the upstream first to reduce risk of discrepancies?

The rule of thumb is to commit to llvm-project directly and rely on pulldown script to bring the change to intel/llvm repository. The change can be committed to intel/llvm directly if there is a justification to bypass the default process. Why do we want to merge this patch ahead of llvm/llvm-project#114790?

[AlexeySachkov]

@elizabethandrews, @bader, PR to the upstream is published here: llvm/llvm-project#114790, are you ok with merging this change to intel/llvm in advance, or should we wait for the upstream first to reduce risk of discrepancies?

The rule of thumb is to commit to llvm-project directly and rely on pulldown script to bring the change to intel/llvm repository. The change can be committed to intel/llvm directly if there is a justification to bypass the default process. Why do we want to merge this patch ahead of llvm/llvm-project#114790?

I don't think that there is a rush with this one, but it is ready to merge, because it was approved by @elizabethandrews. Its better to explicitly request changes, or move it to draft then to prevent an accidental merge, I essentially wanted to double-check here.