On 01/10/2026 12:21, Richard Biener wrote: > On Thu, Oct 1, 2026 at 10:03 AM Torbjorn SVENSSON > <[email protected]> wrote: >> >> >> >> On 2026-10-01 08:40, Richard Biener wrote: >>> On Wed, Sep 30, 2026 at 8:06 PM Torbjorn SVENSSON >>> <[email protected]> wrote: >>>> >>>> >>>> >>>> On 2026-09-30 10:01, Richard Biener wrote: >>>>> On Tue, Sep 29, 2026 at 3:32 PM Torbjorn SVENSSON >>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 2026-09-29 14:57, Richard Biener wrote: >>>>>>> On Tue, Sep 29, 2026 at 9:52 AM Torbjorn SVENSSON >>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2026-09-24 15:56, Richard Biener wrote: >>>>>>>>> On Thu, Sep 24, 2026 at 3:34 PM Torbjorn SVENSSON >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2026-09-24 15:25, Richard Biener wrote: >>>>>>>>>>> On Thu, Sep 24, 2026 at 2:24 PM Torbjorn SVENSSON >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2026-09-23 15:40, Richard Biener wrote: >>>>>>>>>>>>> On Wed, Sep 2, 2026 at 1:18 PM Torbjörn Svensson via Sourceware >>>>>>>>>>>>> Forge >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> From: Torbjörn SVENSSON <[email protected]> >>>>>>>>>>>>>> >>>>>>>>>>>>>> vect_slp_v2qi_store_unalign tests whether the vectorizer handles >>>>>>>>>>>>>> a V2QI >>>>>>>>>>>>>> store through a byte-aligned base, but some -Wstringop-overflow >>>>>>>>>>>>>> tests >>>>>>>>>>>>>> instead depend on a V2QI store at a known one-byte misalignment >>>>>>>>>>>>>> from a >>>>>>>>>>>>>> defined object. >>>>>>>>>>>>>> >>>>>>>>>>>>>> These two variants are not the same on armv7ve with >>>>>>>>>>>>>> -mfloat-abi=hard. >>>>>>>>>>>>>> Add a separate effective target for the latter case. >>>>>>>>>>>>> >>>>>>>>>>>>> Can you again explain why they are not the same? I'm guessing >>>>>>>>>>>>> it's >>>>>>>>>>>>> about knowing the misalignment vs. unknown misalignment but then >>>>>>>>>>>>> vect_slp_v2qi_store_misalign vs. _unalign is not obvious. Maybe >>>>>>>>>>>>> _unknown_misalign vs. _known_misalign? But I'm still curious >>>>>>>>>>>>> why a target choses to allow one but not the other (for stores >>>>>>>>>>>>> there's >>>>>>>>>>>>> no dr_explicit_realign[_optimized])? >>>>>>>>>>>> >>>>>>>>>>>> Unless I've completly missunderstood the sequence, it should stem >>>>>>>>>>>> from >>>>>>>>>>>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/arm.cc;hb=refs/heads/trunk#l30984 >>>>>>>>>>>> >>>>>>>>>>>> After another bisect, I identified that the first failing commit is >>>>>>>>>>>> r16-4314-g5e9eecc6686 (for r16-4315 and later, >>>>>>>>>>>> r16-4355-g53085a46e7f162 >>>>>>>>>>>> is also needed to build). >>>>>>>>>>>> >>>>>>>>>>>> I think the reason for the regression is that the value of "align" >>>>>>>>>>>> is >>>>>>>>>>>> not the same for TYPE_ALIGN_UNIT(type) and >>>>>>>>>>>> GET_MODE_UNIT_SIZE(mode). >>>>>>>>>>>> >>>>>>>>>>>> In the v2qi tests, mode would match HImode, thus: >>>>>>>>>>>> >>>>>>>>>>>> - GET_MODE_UNIT_SIZE(HImode) would return 2. >>>>>>>>>>>> - TYPE_ALIGN_UNIT(type) would return 1 for char. >>>>>>>>>>>> >>>>>>>>>>>> So, maybe my patch is not correct and instead the function should >>>>>>>>>>>> simply be like this since NEON apparently accepts unknown >>>>>>>>>>>> alignment: >>>>>>>>>>>> >>>>>>>>>>>> static bool >>>>>>>>>>>> arm_builtin_support_vector_misalignment (machine_mode mode, >>>>>>>>>>>> int misalignment, >>>>>>>>>>>> bool is_packed, >>>>>>>>>>>> bool >>>>>>>>>>>> is_gather_scatter) >>>>>>>>>>>> { >>>>>>>>>>>> if (TARGET_NEON && !BYTES_BIG_ENDIAN && unaligned_access) >>>>>>>>>>>> { >>>>>>>>>>>> HOST_WIDE_INT align = GET_MODE_UNIT_SIZE (mode); >>>>>>>>>>>> >>>>>>>>>>>> if (is_gather_scatter) >>>>>>>>>>>> return true; >>>>>>>>>>>> >>>>>>>>>>>> if (is_packed) >>>>>>>>>>>> return align == 1; >>>>>>>>>>>> >>>>>>>>>>>> /* NEON supports access regardless of the alignment. >>>>>>>>>>>> */ >>>>>>>>>>>> return true; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> return default_builtin_support_vector_misalignment (mode, >>>>>>>>>>>> misalignment, >>>>>>>>>>>> >>>>>>>>>>>> is_packed, >>>>>>>>>>>> >>>>>>>>>>>> is_gather_scatter); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> WDYT? >>>>>>>>>>> >>>>>>>>>>> Yeah, the current code is >>>>>>>>>>> >>>>>>>>>>> /* If the misalignment is unknown, we should be able to >>>>>>>>>>> handle the access >>>>>>>>>>> so long as it is not to a member of a packed data >>>>>>>>>>> structure. */ >>>>>>>>>>> if (misalignment == -1) >>>>>>>>>>> return true; >>>>>>>>>>> >>>>>>>>>>> /* Return true if the misalignment is a multiple of the >>>>>>>>>>> natural alignment >>>>>>>>>>> of the vector's element type. This is probably >>>>>>>>>>> always going to be >>>>>>>>>>> true in practice, since we've already established >>>>>>>>>>> that this isn't a >>>>>>>>>>> packed access. */ >>>>>>>>>>> return ((misalignment % align) == 0); >>>>>>>>>>> >>>>>>>>>>> which says it accepts any misalignment (misalignment == -1) but not >>>>>>>>>>> a known misalignment, of say 3. That's just odd. >>>>>>>>>>> >>>>>>>>>>>> Also, the check "align == 1" in the is_packed branch is probably >>>>>>>>>>>> not >>>>>>>>>>>> doing the right thing since the value in "align" is the size(?) >>>>>>>>>>>> and not >>>>>>>>>>>> the alignment. >>>>>>>>>>> >>>>>>>>>>> yeah, a vector mode of size 1 probably does not exist. Iff we >>>>>>>>>>> accept misalignment == -1 there's no reason to reject "is_packed". >>>>>>>>>>> is_packed just means we cannot reach alignment by peeling. >>>>>>>>>>> There's no good reason to check is_packed. >>>>>>>>>> >>>>>>>>>> So, based on this, maybe the function body could be reduced to: >>>>>>>>>> >>>>>>>>>> { >>>>>>>>>> if (TARGET_NEON && !BYTES_BIG_ENDIAN && unaligned_access) >>>>>>>>>> return true; >>>>>>>>>> >>>>>>>>>> return default_builtin_support_vector_misalignment (mode, >>>>>>>>>> misalignment, >>>>>>>>>> >>>>>>>>>> is_packed, >>>>>>>>>> >>>>>>>>>> is_gather_scatter); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> I can do this change and do a regression test run on it to see if it >>>>>>>>>> causes >>>>>>>>>> any regressions if you think this is better. >>>>>>>>> >>>>>>>>> Looks reasonable. Note the aarch64 variant does >>>>>>>>> >>>>>>>>> if (TARGET_SIMD && STRICT_ALIGNMENT) >>>>>>>>> { >>>>>>>>> if (is_gather_scatter) >>>>>>>>> return true; >>>>>>>>> >>>>>>>>> /* Return if movmisalign pattern is not supported for this >>>>>>>>> mode. */ >>>>>>>>> if (optab_handler (movmisalign_optab, mode) == >>>>>>>>> CODE_FOR_nothing) >>>>>>>>> return false; >>>>>>>>> >>>>>>>>> /* Misalignment factor is unknown at compile time. */ >>>>>>>>> if (misalignment == -1) >>>>>>>>> return false; >>>>>>>>> } >>>>>>>>> return default_builtin_support_vector_misalignment (mode, >>>>>>>>> misalignment, >>>>>>>>> is_packed, >>>>>>>>> >>>>>>>>> is_gather_scatter); >>>>>>>>> >>>>>>>>> so basically defaults for !STRICT_ALIGNMENT. I suppose the equivalent >>>>>>>>> is unaligned_access >>>>>>>>> on the arm side. Compared to your variant with 'return true' it falls >>>>>>>>> through to the >>>>>>>>> default (which tests for movmisalign support of the mode). So if arm >>>>>>>>> can do that for all >>>>>>>>> vector modes a return true sounds good, if not, fallthru to the >>>>>>>>> default hook looks safer. >>>>>>>> >>>>>>>> I tried to use the aarch64 approach, but replaced TARGET_SIMD with >>>>>>>> TARGET_NEON. >>>>>>>> This works for the test in question, but it causes other regressions >>>>>>>> for the >>>>>>>> vect-early-break. >>>>>>>> Then I tried to simply return true for any TARGET_NEON, same result. >>>>>>>> >>>>>>>> After having tried all these ways, I got lazy and simply asked AI if >>>>>>>> it was >>>>>>>> possible to solve this without having the "type" parameter and the >>>>>>>> conclusion >>>>>>>> it gave me was: >>>>>>>> >>>>>>>> There is no generic way for this hook to exactly reproduce >>>>>>>> `TYPE_ALIGN_UNIT(type)` from only `mode`, `misalignment`, and the >>>>>>>> flags: two >>>>>>>> accesses can have the same hook arguments but different element-type >>>>>>>> alignment. >>>>>>>> The broad NEON `return true` passes `Wstringop-overflow-2.c` but adds >>>>>>>> four >>>>>>>> `vect-early-break` failures. The mode-unit rule with an HImode >>>>>>>> adjustment still >>>>>>>> adds those failures; the full comparison is also affected by different >>>>>>>> non-GCC >>>>>>>> components in the prebuilt baseline versus this build. >>>>>>>> >>>>>>>> >>>>>>>> I think it's safe to say that this might be an unsolvable problem. >>>>>>> >>>>>>> But what matters for the target is the mode, not the type. So IMO the >>>>>>> AI is misleading >>>>>>> here or the vectorizer asks for a non-natural aligned vector type >>>>>>> which it should not. >>>>>> >>>>>> I'm not so worried about the diagnostic part of the failure, but I >>>>>> presume that this >>>>>> function also controls what code that might be generated. Thus, this >>>>>> could potentially >>>>>> lead to wrong code or suboptimal code. >>>>>> Obvious, I would like the failure to go away since it's about 160 >>>>>> fail/xpass for these >>>>>> 2 tests. >>>>>> >>>>>> What would you say is the next step to figure out what is going wrong >>>>>> here? >>>>>> >>>>>> In r16-4314-g5e9eecc6686, I see that riscv might also have a similar >>>>>> problem based on >>>>>> this change: >>>>>> >>>>>> { >>>>>> /* If we know that misalignment is a multiple of the element >>>>>> size, we're >>>>>> good. */ >>>>>> - if (misalignment % TYPE_ALIGN_UNIT (type) == 0) >>>>>> + if (misalignment % (GET_MODE_UNIT_SIZE (mode)) == 0) >>>>>> return true; >>>>>> } >>>>>> >>>>>> Have you heard anyone in the riscv gang that noticed a problem here? >>>>> >>>>> Oh, but that is changing misalignment % alignment for misalignment % size >>>>> (which is more conservative). I'd expect TYPE_ALIGN and >>>>> GET_MODE_ALIGNMENT >>>>> to agree (also size!) and if you put an assert to that near the >>>>> single(?) caller of the >>>>> hook that should never fire. >>>>> >>>>> Does it for the testcases you point out regress? >>>> >>>> Sorry, but it can't even get that far... >>>> >>>> I used r16-4313-gb52a90e7a03fef as a baseline and added this change on top: >>>> >>>> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc >>>> index 8b951f3d4a6..0ec5eca0497 100644 >>>> --- a/gcc/config/arm/arm.cc >>>> +++ b/gcc/config/arm/arm.cc >>>> @@ -30670,6 +30670,9 @@ arm_builtin_support_vector_misalignment >>>> (machine_mode mode, >>>> { >>>> HOST_WIDE_INT align = TYPE_ALIGN_UNIT (type); >>>> >>>> + HOST_WIDE_INT mode_unit_size = GET_MODE_UNIT_SIZE (mode); >>>> + gcc_assert (align == mode_unit_size); >>> >>> That's not what I suggested. You were suggesting to re-instantiate >>> the 'type' argument >>> which was removed as redundant, so I suggested to assert type and mode size >>> and >>> alignment agree, not that alignment and size agree. >> >> Oh, sorry. I misunderstood your request. >> >> >> I did another run with this change on top of the same commit: >> >> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc >> index 8b951f3d4a6..1ac4140cc22 100644 >> --- a/gcc/config/arm/arm.cc >> +++ b/gcc/config/arm/arm.cc >> @@ -30670,6 +30670,26 @@ arm_builtin_support_vector_misalignment >> (machine_mode mode, >> { >> HOST_WIDE_INT align = TYPE_ALIGN_UNIT (type); >> >> + HOST_WIDE_INT mode_align = GET_MODE_ALIGNMENT (mode); >> + HOST_WIDE_INT mode_unit_size = GET_MODE_UNIT_SIZE (mode); >> + HOST_WIDE_INT mode_size = GET_MODE_SIZE (mode); >> + HOST_WIDE_INT type_size = tree_to_shwi (TYPE_SIZE (type)); >> + HOST_WIDE_INT type_unit_size = tree_to_shwi (TYPE_SIZE_UNIT (type)); >> + if (mode_size * BITS_PER_UNIT != type_size || mode_unit_size != >> type_unit_size) >> + { >> + fprintf (stderr, "mode_unit_size = " HOST_WIDE_INT_PRINT_DEC >> + ", mode_size = " HOST_WIDE_INT_PRINT_DEC >> + ", mode_align = " HOST_WIDE_INT_PRINT_DEC >> + ", type_unit_size = " HOST_WIDE_INT_PRINT_DEC >> + ", type_size = " HOST_WIDE_INT_PRINT_DEC >> + ", type_align_unit = " HOST_WIDE_INT_PRINT_DEC >> + "\n", >> + mode_unit_size, mode_size, mode_align, >> + type_unit_size, type_size, align); >> + fflush(stderr); >> + abort(); >> + } >> + >> if (is_gather_scatter) >> return true; >> >> >> >> and the result is (while building newlib for the arm-none-eabi toolchain): >> >> CC libm/math/libm_a-k_rem_pio2.o >> mode_unit_size = 4, mode_size = 16, mode_align = 64, type_unit_size = 4, >> type_size = 32, type_align_unit = 4 > > GET_MODE_SIZE is in bytes, there's also GET_MODE_BITSIZE. > GET_MODE_UNIT_SIZE is, I think, > the size of a vector component (so GET_MODE_SIZE (GET_MODE_INNER > (...))) in bytes, it's very confusing > use of 'UNIT' :/
Yeah, given BITS_PER_UNIT, that's just bizarre. Wouldn't GET_MODE_ELEM_SIZE be a better name for a vector element? R. > >> during GIMPLE pass: vect >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/newlib/newlib/libm/math/k_rem_pio2.c: >> In function '__kernel_rem_pio2': >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/newlib/newlib/libm/math/k_rem_pio2.c:166:13: >> internal compiler error: in arm_builtin_support_vector_misalignment, at >> config/arm/arm.cc:30690 >> 166 | int __kernel_rem_pio2(double *x, double *y, int e0, int nx, >> int prec, const __int32_t *ipio2) >> | ^~~~~~~~~~~~~~~~~ >> 0x1b8ddc9 internal_error(char const*, ...) >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/diagnostic-global-context.cc:786 >> 0x6f5939 fancy_abort(char const*, int, char const*) >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/diagnostics/context.cc:1803 >> 0x113ecf1 arm_builtin_support_vector_misalignment >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/config/arm/arm.cc:30690 >> 0x1ac6fae vect_supportable_dr_alignment(vec_info*, dr_vec_info*, tree_node*, >> int, bool) >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-data-refs.cc:6643 >> 0x1ac9229 vect_enhance_data_refs_alignment(_loop_vec_info*) >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-data-refs.cc:2565 >> 0x1055ee5 vect_analyze_loop_2 >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-loop.cc:2408 >> 0x1056c4d vect_analyze_loop_1 >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-loop.cc:2888 >> 0x10573e7 vect_analyze_loop(loop*, gimple*, vec_info_shared*) >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vect-loop.cc:3069 >> 0x10a313b try_vectorize_loop_1 >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vectorizer.cc:1097 >> 0x10a313b try_vectorize_loop >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vectorizer.cc:1217 >> 0x10a3a14 execute >> >> /build/gnu-tools-for-stm32_c1a91159a3f15ac5cb229857e7d266f84bfbdac1/src/gcc/gcc/tree-vectorizer.cc:1331 >> Please submit a full bug report, with preprocessed source (by using >> -freport-bug). >> Please include the complete backtrace with any bug report. >> See <https://gcc.gnu.org/bugs/> for instructions. >> Makefile:38578: recipe for target 'libm/math/libm_a-k_rem_pio2.o' failed >> make[6]: *** [libm/math/libm_a-k_rem_pio2.o] Error 1 >> >>> >>>> + >>>> if (is_gather_scatter) >>>> return true; >>>> >>>> >>>> When I try to build newlib with this (just building a full arm-none-eabi >>>> toolchain), I get the following ICE: >>>> >>>> CC libc/stdlib/libc_a-arc4random.o >>>> during GIMPLE pass: slp >>>> /build/r16-4313-gb52a90e7a03fef/src/newlib/newlib/libc/stdlib/arc4random.c: >>>> In function '_rs_stir': >>>> /build/r16-4313-gb52a90e7a03fef/src/newlib/newlib/libc/stdlib/arc4random.c:94:1: >>>> internal compiler error: in arm_builtin_support_vector_misalignment, at >>>> config/arm/arm.cc:30674 >>>> 94 | _rs_stir(void) >>>> | ^~~~~~~~ >>>> 0x1b8dcb9 internal_error(char const*, ...) >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/diagnostic-global-context.cc:786 >>>> 0x6f5939 fancy_abort(char const*, int, char const*) >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/diagnostics/context.cc:1803 >>>> 0x113ebfc arm_builtin_support_vector_misalignment >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/config/arm/arm.cc:30674 >>>> 0x1ac6e9e vect_supportable_dr_alignment(vec_info*, dr_vec_info*, >>>> tree_node*, int, bool) >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-data-refs.cc:6643 >>>> 0x10187a6 get_load_store_type >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-stmts.cc:2343 >>>> 0x102c1f3 vectorizable_load >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-stmts.cc:9448 >>>> 0x103b23e vect_analyze_stmt(vec_info*, _slp_tree*, _slp_instance*, >>>> vec<stmt_info_for_cost, va_heap, vl_ptr>*) >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-stmts.cc:12665 >>>> 0x108d8e7 vect_slp_analyze_node_operations_1 >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:8065 >>>> 0x108d8e7 vect_slp_analyze_node_operations >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:8334 >>>> 0x108d857 vect_slp_analyze_node_operations >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:8311 >>>> 0x108f6eb vect_slp_analyze_operations(vec_info*) >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:8738 >>>> 0x1094e35 vect_slp_analyze_bb_1 >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:9785 >>>> 0x1094e35 vect_slp_region >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:9832 >>>> 0x1095e6d vect_slp_bbs >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:10055 >>>> 0x10964eb vect_slp_function(function*) >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vect-slp.cc:10177 >>>> 0x10a04fe execute >>>> >>>> /build/r16-4313-gb52a90e7a03fef/src/gcc/gcc/tree-vectorizer.cc:1568 >>>> Please submit a full bug report, with preprocessed source (by using >>>> -freport-bug). >>>> Please include the complete backtrace with any bug report. >>>> See <https://gcc.gnu.org/bugs/> for instructions. >>>> Makefile:22030: recipe for target 'libc/stdlib/libc_a-arc4random.o' failed >>>> >>>> >>>> Does this give you any ideas? >>>> >>>> Would it help to provide the scalar_mode along with the machine_mode to >>>> arm_builtin_support_vector_misalignment in any way? >> >> Is this still on the table, or is this a bad idea? >> >> Kind regards, >> Torbjörn
