[SYCL][E2E] Switch KernelFusion/* tests to use <sycl/detail/core.hpp>

[aelovikov-intel]

Use core.hpp instead of sycl.hpp to improve CI compile times, as described here: https://github.com/intel/llvm/tree/sycl/sycl/test-e2e#sycldetailcorehpp

[victor-eds]

Why is this changed needed? Can we provide an explanation in the PR description?

[aelovikov-intel]

That is described in details in

llvm/sycl/include/sycl/detail/core.hpp

Lines 11 to 19 in e720b3a

	// This is an ongoing experimental activity in its early stage. No code outside
	// this project must rely on the behavior of this header file - keep using
	// <sycl/sycl.hpp>.
	//
	// Short-term plan/action items (in no particular order):
	// * Update more tests to use this instead of full <sycl/sycl.hpp>.
	// * Refactor includes so that transitive dependencies don't bring as much as
	// they currently do.
	// * Determine what else should be included here.

and

llvm/sycl/test-e2e/README.md

Lines 286 to 297 in e720b3a

	## sycl/detail/core.hpp
	While SYCL specification dictates that the only user-visible interface is
	`<sycl/sycl.hpp>` header file we found out that as the implementation and
	multiple extensions grew, the compile time was getting worse and worse,
	negatively affecting our CI turnaround time. We are just starting some efforts
	to create a much smaller set of basic feature needed for every SYCL end-to-end
	test/program so that this issue could be somewhat mitigated. This activity is in
	its early stage and NO production code should rely on it. It WILL be changed as
	we go with our experiments. For any code outside of this project only the
	`<sycl/sycl.hpp>` must be used until we feel confident to propose an extension
	that can provide an alternative.

[sommerlukas]

That is described in details in

llvm/sycl/include/sycl/detail/core.hpp

Lines 11 to 19 in e720b3a

	// This is an ongoing experimental activity in its early stage. No code outside
	// this project must rely on the behavior of this header file - keep using
	// <sycl/sycl.hpp>.
	//
	// Short-term plan/action items (in no particular order):
	// * Update more tests to use this instead of full <sycl/sycl.hpp>.
	// * Refactor includes so that transitive dependencies don't bring as much as
	// they currently do.
	// * Determine what else should be included here.

and

llvm/sycl/test-e2e/README.md

Lines 286 to 297 in e720b3a

	## sycl/detail/core.hpp
	While SYCL specification dictates that the only user-visible interface is
	`<sycl/sycl.hpp>` header file we found out that as the implementation and
	multiple extensions grew, the compile time was getting worse and worse,
	negatively affecting our CI turnaround time. We are just starting some efforts
	to create a much smaller set of basic feature needed for every SYCL end-to-end
	test/program so that this issue could be somewhat mitigated. This activity is in
	its early stage and NO production code should rely on it. It WILL be changed as
	we go with our experiments. For any code outside of this project only the
	`<sycl/sycl.hpp>` must be used until we feel confident to propose an extension
	that can provide an alternative.

Sounds like a good addition!

Can you please add links to core.hpp and that section of the README to the PR description, so it's included in the commit message?

[aelovikov-intel]

Can you please add links to core.hpp and that section of the README to the PR description, so it's included in the commit message?

I think that would be too much overhead to keep adding them to all the PRs... Do you really need it?

[sommerlukas]

Changes LGTM.

Minor nit: There's a few files with an extra blank line after #include <sycl/detail/core.hpp>, but could probably go in as-is.

[aelovikov-intel]

Changes LGTM.

Minor nit: There's a few files with an extra blank line after #include <sycl/detail/core.hpp>, but could probably go in as-is.

Some of them were on purpose - to prevent clang-format from moving core.hpp to after other sycl/* includes. Others just copy-pasted that blank line from those where it was needed. Overall, I think it can go as-is too. I wouldn't be surprised if we'll have to modify the files later on as the core.hpp will get smaller.