linaro / vixl Goto Github PK

We're looking to do some testing of SVE2.1 instructions in the simulator. Would be nice if this is supported.

the following linker errors popped up when I was trying to compile stuff (using the shared library produced with the meson patch):

/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: out/host/linux-x86/obj/lib/libart-compiler.so: undefined reference to `non-virtual thunk to vixl::aarch64::MacroAssembler::ReleasePools()'
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: out/host/linux-x86/obj/lib/libart-compiler.so: undefined reference to `non-virtual thunk to vixl::aarch64::MacroAssembler::EnsureEmitPoolsFor(unsigned long)'
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: out/host/linux-x86/obj/lib/libart-compiler.so: undefined reference to `non-virtual thunk to vixl::aarch64::MacroAssembler::BlockPools()'

these are not exported by the .so:

> nm -C /usr/local/lib/libvixl.so | grep ReleasePools
00000000001d5d70 t vixl::aarch32::MacroAssembler::ReleasePools()
000000000027b680 t vixl::aarch64::MacroAssembler::ReleasePools()
00000000001d5d80 t non-virtual thunk to vixl::aarch32::MacroAssembler::ReleasePools()
000000000027b6b0 t non-virtual thunk to vixl::aarch64::MacroAssembler::ReleasePools()

but maybe they're supposed to be duplicated locally?
it appears they are for the aarch32 version...

> nm -C out/host/linux-x86/lib64/libart-compiler.so | grep ReleasePools
0000000000174c40 W vixl::aarch32::MacroAssembler::ReleasePools()
0000000000174c50 W non-virtual thunk to vixl::aarch32::MacroAssembler::ReleasePools()
                 U non-virtual thunk to vixl::aarch64::MacroAssembler::ReleasePools()

This can be "solved" by not allowing gcc to devirtualize these calls, at which point there is nothing to link and everything is fine.
I wasn't able to get gcc to devirtualize these in a small, self-contained example, but hopefully it's reproducible in https://gitlab.com/android_translation_layer/art_standalone/-/blob/e67c821e/art/compiler/utils/arm64/assembler_arm64.h#L58 (linked here the workaround that would need to be removed to reproduce the issue) not just with my setup (though the setup in question is an alpine aarch64 chroot so it should probably be possible to replicate that in the worst case)

I guess this might be an issue with GCC rather than with vixl, but I don't want to claim a compiler bug if I don't even fully understand how is the code supposed to compile

Hi,

Can you create a new release/tag please? Or can I use the HEAD of the main branch safely?
The main feature I want to have is the compatibility fixes with MSVC added last year

Hi,

I was recently trying to use the 128-bit version of the PMULL instructions that take in 64-bit values and produce a 128-bit carryless product (akin to PCLMULQDQ on x86), however the implementation currently only seems to support 8-bit value inputs and producing 16-bit products (unless there's a separate opcode function to handle this case that I'm not aware of).

Could this other case be supported as well?

There are a few places where the aarch64 code uses -operand.immediate(). If the immediate is INT64_MIN, the behavior is undefined.

This was fixed for Add and Sub in 2020 in b8da04d, but the same pattern still shows up in Ccmp, Ccmn, and Neg.

We (Mozilla) ran into this because our fork didn't have the fix for Add and Sub and it was causing problems with recent Clang versions, but we then noticed the same pattern is still present in these other methods.

hello, casX implementation is not atomic?

Currently the AFP extension is completely unsupported.
Ideally I want to implement features using FPCR.NEP for when new hardware launches that supports it but currently the vixl simulator lacks this feature.
It would be nice if this could be added to the simulator so my project can be ready once future hardware launches.

Reading the pseudocode in the ARM reference manual, AdvSIMD FCVTL stores the result of the conversion using V[d, 2*esize] = result;, where V[] is defined to zero-extend the 128-bit vector result into the underlying SVE Z register. Though it seems that vixl doesn't do that in this particular instance.

So, if I had a layout in a 256-bit Z register like: (LHS being low bits and RHS being high bits in 64-bit element increments)

[0, 0, 0xFFFFFFFFFFFFFFFF, 0xFFFFFFFFFFFFFFFF]

and executed an FCVTL instruction, the upper 128-bits of the 256-bit register would erroneously still remain set.

Making a cursory look at the handling for the logic, it seems that the handling for FCVTN, on the other hand, does handle marking the upper bits as cleared, but FCVTL's handling doesn't.

It also seems like FCVTL2/FCVTN2 would have the same issue in the context of SVE-256.