[SYCL] Fix handling of structs with trailing padding in SpecConstants pass

[AlexeySachkov]

This patch fixes a regression accidentally introduced in #9874 (presumably because we didn't have the right test).

SYCL-CTS produces an LLVM IR pattern, where spec constant initializer contains less elements than there are in a spec constant type, because some of those elements are implicitly-created paddings. The patch updates the pass to handle this situation.

Note: this PR only covers a case when padding is inserted at the end of a struct.

Resolves #10129

[AlexeySachkov]

@intel/sycl-language-enabling-triage: FYI

[asudarsa]

Hi @maksimsab

Can you please take a look at this PR?

Thanks

[KseniyaTikhomirova]

test sycl/test-e2e/SpecConstants/2020/non-packed-struct.cpp LGTM. compiler part is out of my expertise

[AlexeySachkov]

@intel/dpcpp-tools-reviewers, @maksimsab, could you please take a look?

[maksimsab]

Looking into it.

[maksimsab]

@AlexeySachkov
I can see the following type case in the test: type <{ float, i32, i8, [3 x i8] }>.
Does it worth to also consider the case like this: type <{ i32, i8, [3 x i8], i8, [3 x i8] }> ? Here we have a padding not only in the end, but in the middle of the struct as well.

[AlexeySachkov]

@AlexeySachkov I can see the following type case in the test: type <{ float, i32, i8, [3 x i8] }>. Does it worth to also consider the case like this: type <{ i32, i8, [3 x i8], i8, [3 x i8] }> ? Here we have a padding not only in the end, but in the middle of the struct as well.

Good point, let me add a test like this to see if there are more problems related to paddings

[AlexeySachkov]

@AlexeySachkov I can see the following type case in the test: type <{ float, i32, i8, [3 x i8] }>. Does it worth to also consider the case like this: type <{ i32, i8, [3 x i8], i8, [3 x i8] }> ? Here we have a padding not only in the end, but in the middle of the struct as well.

Good point, let me add a test like this to see if there are more problems related to paddings

@maksimsab, we indeed don't support the case when padding is embedded into a structure and it causes crash on assertion. However, I would like to proceed with the current PR as-is, if possible, because it unblocks build of SYCL-CTS specialization constant tests. Apparently, the new case you have suggested is not tested by CTS and I think that it therefore should be ok to address it in a separate PR.

[maksimsab]

LGTM