[CI] Introduce SPIR-V Backend support in LIT config

[VyacheslavLevytskyy]

We introduce here SPIR-V Backend support in LIT config by adding a new LIT feature 'spirv-backend', and in a way that substitutions in end-to-end tests are aware about the new LIT feature.

[VyacheslavLevytskyy]

It was agreed that we split #16317 into three parts:

• CI
• Clang driver
• XFAIL & UNSUPPORTED in end-to-end tests.
  This is the 1st part, copy-pasted from [E2E] Introduce SPIR-V Backend support in SYCL tests and end-to-end tests #16317 with a couple of changes suggested by the code review.

[aelovikov-intel]

I think the main problem is our choice for the %{sycl_triple} substitution. If it included the entire option and not its value only, we could have extended that, and it would make the most sense. IIUC, spirv-backend option is only needed when we use -fsycl-targets=spir*[,.*]*. As such, fixing that might be the right way to implement this PR.

@sarnex , @steffenlarsen , @AlexeySachkov , WDYT?

[AlexeySachkov]

@AlexeySachkov , WDYT?

Do we have a test which needs %{sycl_triple} for something other than -fsycl-targets? If not, then I fully support replacing it with something like %{fsycl-targets} which will simplify passing extra arguments which are unique to specific targets

[aelovikov-intel]

llvm/sycl/test-e2e/Regression/multiple-targets.cpp

Line 7 in 3abd321

// RUN: %clangxx -fsycl -fsycl-targets=%{sycl_triple},spir64 -o %t1.out %s

, unfortunately.

[AlexeySachkov]

I still think that its a good idea to have a higher-level substitution, even if some tests won't be using it (I assume that there are just a small fraction of tests which pass triple explicitly because they want to test something specific).

And we can decide on a case-by-case basis if any of those remaining tests needs to be specialized to run with SPIR-V backend.

I also wouldn't block the PR on this refactoring: considering that passing -fsycl-use-spirv-backend-for-spirv-gen won't do anything for non-SPIRV targets the refactoring seems to be unrelated to this and the code doesn't look that bad to me in its current form.

[sarnex]

sorry is the idea here to make sycl_triple be -fsycl-targets=whatever,whatever instead of whatever,whatever and if this feature is enabled we just append the option to sycl_triple? if so sounds good to me

[aelovikov-intel]

If it "won't do anything", just pass it inside %clangxx. That would make it working for tests that don't use %{build}.

[VyacheslavLevytskyy]

The logic of the change is that %{build} means now two different things, either "build with support of SPIR-V Backend" or "build", whereas previously it meant just "build". It's implemented by modifying %{build} contents depending on the use case.

I has no personal preference as for the way of how to implement this. We need to pass -fsycl-use-spirv-backend-for-spirv-gen parameter as the part of %{build} when "spirv-backend" is in test.config.available_features, that's all.

[aelovikov-intel]

The logic of the change is that %{build} means now two different things

I'm not sure what you mean, but it doesn't sound right to me.

We need to pass -fsycl-use-spirv-backend-for-spirv-gen parameter as the part of %{build} when "spirv-backend" is in test.config.available_features, that's all.

I don't agree with this either. IMO, we need to pass the option anytime we're compiling for spirv triple, and %{build} is definitely the wrong place to do that.

[sarnex]

i dont have strong enough of an opinion to hold up the PR on the sycl_targets thing, but probably andrei should state his opinion before merging

[sarnex]

Suggested change

	It's possible to use the LLVM SPIR-V Backend instead of llvm-spirv tool to
	It's possible to use the LLVM SPIR-V Backend instead of the `llvm-spirv` tool to

[VyacheslavLevytskyy]

I rebased the PR to #16614 and aligned with refactoring of the %{sycl_target_opts} substitution.

[steffenlarsen]

LGTM!