This obscure 1990 technical review from the U of Sydney refers to "vector pipelining" as a means of implementing SIMD under the hood — if you suppose that the processor doesn't have enough logic to execute a vector instruction in "full width" at one go, but that the instruction can be broken down into sub-operations (at a level below instruction set level), then there's a performance gain to be had by pipelining those sub-operations, so that processing n times as much data takes less than n times as long.
To illustrate a little bit, suppose that the 8x8=8 bit operation "swizzle" takes 4 clocks, and can be conveniently broken down into four 1-clock stages. Our chip also has eight independent swizzle units.
We can swizzle one pair of values in 4 clocks.
With SIMD, we can swizzle up to 8 pairs of values (64x64=64 bits) by engaging all of the swizzle units at once.
Without pipelining, a 16-wide (128x128=128) swizzle instruction would take 8 clocks, and a 32-wide (256x256=256) swizzle instruction would take 16 clocks.
With vector vector pipelining, the chip can introduce the first 8 operands to the first stage of the swizzle pipeline on clock 1 (to emerge on clock 4), the second set on clock 2 (to emerge on clock 5), etc. Assuming nil overhead of breaking up and reassembling the operands, and assuming I've understood this all right, then you can have a 16-wide swizzle in 5 clocks, and a 32-wide swizzle in 7.
Whether modern architectures have (or need) anything like this, I'm afraid I don't know.