[SYCL] Use aux triple when mangling neon vectors

[frengels]

The aux triple needs to be passed for the mangling to go into the correct function.
Without this the arm_neon.h header will generate unsigned poly types as is done
for aarch64. But due to not checking the aux triple it will require the arm signed poly types.

[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.

[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).

[tahonermann]

Thanks, @frengels, this looks good to me.

[elizabethandrews]

@bader I see tests have not run for this PR, with the message "This workflow requires approval from a maintainer". I've never encountered this before. Can I approve the workflows?

[sys-ce-bb]

@intel/llvm-gatekeepers please consider merging

[bader]

@bader I see tests have not run for this PR, with the message "This workflow requires approval from a maintainer". I've never encountered this before. Can I approve the workflows?

@elizabethandrews, please, read https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#controlling-changes-from-forks-to-workflows-in-public-repositories to understand the reasons for this repository workflows configuration.

By default, all first-time contributors require approval to run workflows.

If PR changes look reasonable, you can approve the workflow run.

[elizabethandrews]

@frengels looks like the tests don't pass. Can you please take a look? There also appears to be a ClangFormat error.

[frengels]

Fixed up the test. The issue was that due to the upstream change which fixed the original issue being made in a different location, it doesn't error even when using a bad poly type (32-bit).
So I'm having the test comply with that behavior.