On 24/06/2026 10:08, Richard Biener wrote:
On Tue, Jun 9, 2026 at 11:24 AM Richard Biener
<[email protected]> wrote:
On Wed, Jun 3, 2026 at 5:20 PM Christopher Bazley <[email protected]> wrote:
Add two new fields to SLP tree nodes, which are accessed as
SLP_TREE_CAN_USE_PARTIAL_VECTORS_P and SLP_TREE_PARTIAL_VECTORS_STYLE.
SLP_TREE_CAN_USE_PARTIAL_VECTORS_P is analogous to the existing
predicate LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P. It is initialized to
true. This flag just records whether the target could vectorize a
node using a partial vector; it does not say anything about
whether the vector actually is partial, or how the target would support
use of a partial vector. Some kinds of node require mask/length for
partial vectors; others don't. In the latter case (e.g., for add
operations), SLP_TREE_CAN_USE_PARTIAL_VECTORS_P will remain true.
SLP_TREE_PARTIAL_VECTORS_STYLE is analogous to the existing field
LOOP_VINFO_PARTIAL_VECTORS_STYLE. Both are initialized to 'none'.
The vect_partial_vectors_avx512 enumerator is not used for BB SLP.
Unlike loop vectorization, a different style of partial vectors can be
chosen for each node during analysis of that node.
To add, SLP_TREE_PARTIAL_VECTORS_STYLE should not be per SLP node but
per 'vinfo'. It doesn't make much sense to have differing styles
active. So please
just move the partial vectors style from loop_vinfo to the vinfo base class.
The overall commit message does not mention SLP_TREE_NUM_PARTIAL_VECTORS
you add per node and why. It definitely shouldn't live there, it's an
Sorry about that. I probably forgot to explain it in my commit message
because it was a relatively late change in v9 of my patch series:
("A new per-SLP-node variable, SLP_TREE_NUM_PARTIAL_VECTORS, is
now used to calculate a worst-case estimate of the cost of
creating masks or lengths for partial vector tails. This aligns
BB SLP with existing costing of vectorised loops.")
odd counter
that's going to be 0 or 1 exactly when we decide to (possibly) use
partial vectors?
It is a counter because I did not want to assume anything about how many
times vect_slp_record_bb_mask or vect_slp_record_bb_len might be called.
As said, I think we want to re-use the loop mask/len tracking here.
Right, that is what I've done in the revised patch series that I'm
testing locally.
Thanks,
--
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/
