[SYCL] Disable diagnostics for neon attributes for SYCL device compilation

[frengels]

This would previously error out as the aux triple wasn't used for checking against neon vector types. Now the aux target is used when sycl is enabled for both sema and mangling.

Changes in ItaniumMangle.cpp are to make this aux-triple and SYCL aware, which will cause us to go into aarch64 mangling path that correctly handles long long for windows.

Checks are added to SemaType to ensure that the selected long or long long is indeed 64-bit, previously this would allow 32-bit long to be a valid polyvector type (which it's not).

These are both tested with neon-polyvector-types.cpp. The -verify lines check for error for non 64-bit types, long on windows and int on linux. The -verify=quiet ensures that we use the aarch64 mangling path, the non aarch64 mangling path only accepts long long and not long.

[elizabethandrews]

What was the diagnostic you were seeing before this change? @tahonermann can you take a look at this as well?

[tahonermann]

I'm somewhat confused about what the root problem really is. As far as I can tell, NEON polynomial vectors can have base types that are 32-bit (according to ARM documentation) so long as the element count is correct.

The fix for mangling more or less makes sense, though I'm not sure why we would care that mangling of vector types is consistent across host and device compilation.

I noted a few other issues.

[tahonermann]

getAuxTargetInfo() will return null if an auxiliary target wasn't specified (which is commonly the case in tests).

[tahonermann]

getAuxTargetInfo() will return null if an auxiliary target wasn't specified (which is commonly the case in tests).

[tahonermann]

This doesn't seem right to me. The allowed base types should be independent of the type size. The actual constraint (checked in HandleNeonVectorTypeAttr()) is that the size of the base type multiplied by the number of elements must match the vector size (64-bit or 128-bit).

Is the root problem that unsigned long and unsigned long long have different type sizes for device vs host? If so, we should fix that (even though the SYCL specification doesn't require it).

[tahonermann]

Is it important to constrain the specific types used as the base type? Perhaps it would make sense to check for any builtin unsigned integral type with one of the allowed sizes (8, 16, or 64 bit)? Something like:

      return BTy->isUnsignedInteger() &&
             llvm::any_of(S.Context.getTypeSize(BTy), [](uint64_t n) {
                 return n == 8 || n == 16 || n == 64
             };

[frengels]

That's what I thought as well, I didn't want to upset the status quo. This would make it simpler and more legible.

[frengels]

I don't see poly32_t mentioned in the docs I'm referencing. https://arm-software.github.io/acle/main/acle.html#vector-data-types

Vector data types ^

The base types are ..., poly8_t, poly16_t, poly64_t, poly128_t, and ... .
Could you point me to where it mentions poly32_t as one of the types?

[tahonermann]

Could you point me to where it mentions poly32_t as one of the types?

Perhaps that is a documentation mistake. That same doc includes both int32_t and uint32_t as base types. This doc states that intrinsics exist for 32-bit base types.

The Arm Neon architecture uses a 64-bit or 128-bit register file. In a 64-bit case, you can work with either eight 8-bit, four 16-bit, or two 32-bit elements. In a 128-bit case, you can work with either sixteen 8-bit, eight 16-bit, four 32-bit, or two 64-bit elements.
...
<type> is the data type (int, uint, float, or poly).
<size> is the number of bits used for the data type (8, 16, 32, 64).
<number of lanes> defines how many lanes.

I don't see any explicit indication that 32-bit poly types are not supported; most of the docs can be read as implying that they are.

[tahonermann]

I don't see any explicit indication that 32-bit poly types are not supported; most of the docs can be read as implying that they are.

Sorry, ignore me, I clearly don't know what I'm talking about. When I looked further, other documents do make it clear that poly32_t is not a thing.

[frengels]

What was the diagnostic you were seeing before this change? @tahonermann can you take a look at this as well?

The original diagnostic was

C:\repos\intel-llvm\build\buildbot-native-Release\lib\clang\21\include\arm_neon.h:45:24: error: invalid vector element type 'poly8_t' (aka 'unsigned char')
   45 | typedef __attribute__((neon_polyvector_type(8))) poly8_t poly8x8_t;
      |                        ^

This could be reproduced by any file on windows (possibly also linux) including arm_neon.h. The aux target's defines would be enabled and therefore define poly8_t as uint8_t. But later during Sema in isPermittedNeonBaseType it no longer knows about being aarch64 causing it to require signed integers and resulting in that error.

Now the current situation is that the error we ran into has been fixed in 48b7530, I hadn't seen these when posting this change. I'll remove the SYCL offloading changes from Sema and focus on the ItaniumMangle.cpp changes, and test cases. The issue with ItaniumMangle.cpp being similar to the earlier however only occurring on linux. Again losing the target info causing to enter the wrong mangling function (arm vs aarch64).