Open paultag opened 3 years ago
Please see #40725
(I think the above comment is a reference to the following comment from that thread:)
Please don't take this as a critisism, but as an observer of a number of this class of request, the best results are obtained when the OP, you in this case, can enumerate exactly which instructions to add. I have no explanation why requests for all XXX instructions are unsuccessful, but encourage you to list precisely the instructions you would like to see added as there is anecdotal evidence that requests formed in this way are resolved faster.
I'll go shopping for opcodes, thanks @davecheney. I was going to try to put together a changeset to go with this issue, but figured I'd file it ahead of that in case it wound up being an insurmountable pile of internals changes. I'll list opcodes I'm in need of here, and see if I can produce a changeset (famous last bugreport words)
After looking at a few similar changes adding arm64 opcodes, I suspect I'm in over my head. I'm still going to try my hand at a changeset for sheer sport, but I wouldn't block on me if anyone competent comes across this issue.
These are the most burning opcodes to help remove some bottlenecks I've hit:
VFABD
VFMAX
, VFMAXNM
, VFMINNM
VFMIN
VFADD
, VFSUB
VFMUL
, VFDIV
VFMLA
, VFMLS
VCVT
(Not sure what the correct instruction opcode(s) in idiomatic Go ASM would be here are -- the ones that i'd want would be "float to unsigned integer", "float to signed integer", "signed integer to float" and "unsigned integer to float" variants)/cc @cherrymui
@cherrymui Is there any way I can help on this? I'm also interested in this. Just don't really know where to start.
For those reading this and not being able to wait for the implementation, you can do the following:
float32x4_t t;
t = vaddq_f32(t, t);
- compile and disassemble the binary with otool or objdump. e.g for otool:
$ gcc main.c $ otool -tvj a.out ... ... 4e20d420 fadd.4s v0, v1, v0 ...
the -j prints opcode bytes
- take the opcode and load it with the WORD instruction into your assembly code:
WORD $0x4e20d420 // fadd.4s v0, v1, v0
⚠️ be aware of operand order !
I totally forgot to post similar after I did my work - I eventually published the code I was working on, here's a link for future travelers (although I wound up hacking up a simple assembler in Python using the arm64 opcode PDF, the code got lost a few machines ago but it wasn't particularly smart, this compiler method is a better idea) -- thanks for the post and reminder @Clement-Jean
@Clement-Jean thank you for being interested in contributing! The source code of the ARM64 assembler backend is at https://cs.opensource.google/go/go/+/master:src/cmd/internal/obj/arm64/ . It is not hard to add support of a new instruction, given that we already support similar instructions. Thanks.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Whilst writing some NEON code, I found myself in need of floating point operations in NEON. I was able to load my data to the
V*
registers (and write it out!), but when I attempted to useVF*
instructions, such asVFADD
orVFMUL
, those opcodes have not been implemented by any intrepid engineer on arm64.What did you expect to see?
Vectorized floating point addition or multiplication.
What did you see instead?
unrecognized instruction "VFADD"
Test code
neon.go
neon_test.go
neon_arm64.s