Vector API: VectorMask.fromLong is not intrinsified

Jakub Okoński jakub at okonski.org
Mon Oct 14 21:19:32 UTC 2024


Hi Paul,

You're right. I had multiple of these and copied the wrong one to show as
an example here. A different one was using `species` as a local variable,
which was not constant enough to apply the intrinsic.

Overall, I'm having a hard time navigating PrintIntrinsics, PrintInlining
and PrintAssembly. With the right set of CompileCommand=inline, I can get
it to reduce allocations further and apply intrinsics more often, but never
reduce allocations down to zero.

Though as long as I contain all my vector code to a single method,
everything I throw at gets intrinsified and doesn't allocate, so that's
great!

Regards,
Jakub

On Mon, 14 Oct 2024 at 17:58, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Jakub,
>
> You should only need to use a constant species, the log output indicates
> it is not contrary to the code you show. Is your actual code different?
>
> The HotSpot code you link to requires that the vector/mask class, element
> class (etype), and vector length be constants, these all come from the
> species. So if the species is constant they will be. Strangely your log
> output indicates the element class is constant but the vector/mask class
> and vector length are not.
>
> Paul.
>
> On Oct 13, 2024, at 11:01 AM, Jakub Okoński <jakub at okonski.org> wrote:
>
> Hi Rado,
>
> That makes sense and making it static final did help inline these
> intrinsics in my benchmark, thank you.
>
> Regards,
> Jakub
>
> On Sun, 13 Oct 2024 at 18:27, <rsmogura at icloud.com> wrote:
>
>> Hi Kuba,
>>
>> I hope you are well.
>>
>> Without code being seen it's hard to troubleshoot issue with 100%
>> certainty.
>>
>> However, I wonder if not being constant OOP can be cause that maks or
>> someInt is not constant. it's preferred that vectors and mask will be
>> declared as static final (which is considered const by VM), and than VM can
>> apply more stronger optimisations.
>>
>> Best regards,
>> Rado
>>
>> On 12 Oct 2024, at 23:25, Jakub Okoński <jakub at okonski.org> wrote:
>>
>> Hi,
>>
>> I noticed that the following code doesn't get intrinsified:
>>
>>     VectorMask.fromLong(ByteVector.SPECIES_128, someInt)
>>
>> Profiling with JFR reveals that this method falls back to fromArray and
>> allocates a boolean[], which is undesirable.
>>
>> It has to be this fallback code:
>> https://github.com/openjdk/jdk/blob/41ee582df8c65f2f26b21e46784cf0bc4ece0585/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java#L252
>>
>> With PrintIntrin, I'm seeing this message
>>
>> ** missing constant: vclass=DecodeN etype=ConP vlen=LoadI bitwise=ConI
>>
>> I modified the logging and narrowed it down to vector_klass->const_oop()
>> being a nullptr
>>
>>
>> https://github.com/openjdk/jdk/blob/41ee582df8c65f2f26b21e46784cf0bc4ece0585/src/hotspot/share/opto/vectorIntrinsics.cpp#L833
>>
>> I then tried to cheat and hardcode the vector class and lane count in
>> VectorMask.java so it knows the arguments statically, like so:
>>
>>         return VectorSupport.fromBitsCoerced((Class<? extends
>> AbstractMask<E>>) (Class<?>) Byte128Vector.Byte128Mask.class,
>> vsp.elementType(), 16, bits, ...
>>
>> While this did make inlining happen (as reported by PrintIntrin at
>> least), I couldn't get rid of the boolean[] allocations.
>>
>> I'm testing on 41ee582df8c65f2f26b21e46784cf0bc4ece0585 amd64 Linux.
>>
>> Regards,
>> Jakub
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20241014/ff1c9580/attachment-0001.htm>


More information about the panama-dev mailing list