RFR: 8323582: C2 SuperWord AlignVector: misaligned vector memory access with unaligned native memory [v3]

[Roland Westrelin]

On Thu, 20 Feb 2025 09:39:59 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>>> So the overhead in the final code is 2x: we can expect the fast and slow paths to be about the same size so the section of code for the loop would see its size grow by 2x.
>> 
>> Yes, if you get to the point where you add a multi-version-if condition, i.e. where SuperWord has decided it needs a speculative assumption (here for alignment, later for aliasing), then we get the whole loop 2x. I suppose we could try to make the pre-main-post loop more complicated and just multi-version the main-loop, but that sounds much more complicated.
>> 
>> Do you see any better way than having the 2x code size if we need both a slow and fast loop?
>
>> Do you see any better way than having the 2x code size if we need both a slow and fast loop?
> 
> No but I was confused by your comment about 3x and 4x which is why I asked for clarification.
> Compiled code size affects inlining decisions: if a callee has compiled code and it's larger than some threshold, then the callee is considered too expensive to inline. With your change, some method that was considered ok to inline could now be considered too big. I think that's what Vladimir is concerned by. I don't see what you can do about it, this said.

> @rwestrel I think I had tried some verifications above, but I could not even get it to work in all cases in `SuperWord`.
> 
> In `VLoop::check_preconditions_helper`, I try to find either the predicate or the multiversioning if. But I cannot always find it, and I think that one reason was that the pre-loop can be lost. At least that is what I remember from 4+ weeks ago.

Do you understand when that happens? It doesn't feel right that the pre loop can be lost.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22016#issuecomment-2670971210