[NFC][SYCL] Refactor SpecConstantsPass

[maksimsab]

To improve readability of SpecConstantsPass::run function, some of its content is outlined into a separate helper functions.

[AlexeySachkov]

With SYCL 2020, we must always have a default value available, which means that the function should not be called try, we should not use dyn_cast<GlobalVariable>, but instead use cast, etc. The latter could be a bit of a problem in case there is a complex chain of instructions leading from the argument to a global variable, but it should be compile-time resolvable with something like llvm::getUnderlyingObject, for example.

Once again, it is probably better to have this change in a separate PR, because it may cause some regressions if we miss some corner cases. Better not mix it with a non-functional refactoring, but let's have a TODO comment here somewhere about it.

[maksimsab]

With SYCL 2020, we must always have a default value available

But here we check that sycl-post-link is able to come up with default value from type

llvm/llvm/test/tools/sycl-post-link/spec-constants/composite-default-value.ll

Lines 4 to 6 in b7a43a4

	; This test checks that composite specialization constants can be correctly
	; initialized by sycl-post-link tool for AOT use-case (default initialization
	; should be used according to the type of constant)

[AlexeySachkov]

That is likely an outdated/legacy test case and the comment. Yes, old 1.2.1 extension implementation used to set default values based on type in AOT mode, because there were no way to set them in source code.

With SYCL 2020, default value is defined by user when constructing specialization_id object:

Effects: Constructs a specialization_id containing an instance of T initialized with args..., which represents the specialization constant’s default value.

And the value is guaranteed to be compile-time known:

the specialization_id variable must be declared as constexpr;

[maksimsab]

I removed this test.

[AlexeySachkov]

Unrelated to the PR, just an observation: we have at least one more place where we insert some padding metadata:

llvm/llvm/tools/sycl-post-link/SpecConstants.cpp

Lines 252 to 262 in 61c7c64

	SpecConstantDescriptor Desc;
	// ID of padding descriptors is the max value possible. This value is a
	// magic value for the runtime and will just be skipped. Even if there
	// are many specialization constants and every constant has padding of
	// a different length, everything will work regardless rewriting
	// the descriptions with Desc.ID equals to the max value: they will just
	// be ignored at all.
	Desc.ID = std::numeric_limits<unsigned>::max();
	Desc.Offset = LocalOffset;
	Desc.Size = PostStructPadding;
	Result.push_back(Desc);

These paddings are hard and its been a while since I looked into this code. It would be good to refresh that knowledge to see if we could unify adding those paddings or at least add more explanatory comments, because right now I'm not sure that I understand why do we have both those places where we add special descriptors