[RFC PATCH 1/5] vect: Force alignment peeling to vectorize more early break loops

Richard Sandiford richard.sandiford@arm.com
Tue Nov 19 17:02:28 GMT 2024


Sorry for the slow review.  Finally catching up on backlog.

Richard Biener <rguenther@suse.de> writes:
> On Mon, 28 Oct 2024, Alex Coplan wrote:
>
>> This allows us to vectorize more loops with early exits by forcing
>> peeling for alignment to make sure that we're guaranteed to be able to
>> safely read an entire vector iteration without crossing a page boundary.
>> 
>> To make this work for VLA architectures we have to allow compile-time
>> non-constant target alignments.  We also have to override the result of
>> the target's preferred_vector_alignment hook if it isn't a power-of-two
>> multiple of the TYPE_SIZE of the chosen vector type.
>> 
>> There is currently an implicit assumption that the TYPE_SIZE of the
>> vector type is itself a power of two.  For non-VLA types this
>> could be checked directly in the vectorizer.  For VLA types I
>> had discussed offline with Richard S about adding a target hook to allow
>> the vectorizer to query the backend to confirm that a given VLA type
>> is known to have a power-of-two size at runtime.
>
> GCC assumes all vectors have power-of-two size, so I don't think we
> need to check anything but we'd instead have to make sure the
> target constrains the hardware when this assumption doesn't hold
> in silicon.

We did at one point support non-power-of-2 for VLA only.  But things
might have crept in since that break it even for VLA.  It's no longer
something that matters for SVE because the architecture has been
tightened to remove the non-power-of-2 option.

My main comment on the patch is about:

+  /* Below we reject compile-time non-constant target alignments, but if
+     our misalignment is zero, then we are known to already be aligned
+     w.r.t. any such possible target alignment.  */
+  if (known_eq (misalignment, 0))
+    return 0;

When is that true for VLA?  It seems surprising that we can guarantee
alignment to an unknown boundary :)  However, I agree that it's the
natural consequence of the formula.

Thanks,
Richard




More information about the Gcc-patches mailing list