NEON intrinsics

Project Infrastructure LLVM Dev List Archives
1

Third question: (sorry)

NEON intrinsics. Some of them are direct operations (types are the
same, return type is the same), some of them are intrinsics.

So far so good, but why not make them all intrinsics? I mean, it's ok
to have ADD <i8 x 8> transform into a NEON operation, but why not have
*also* the intrinsic for VADD? I've seen some intrinsics get changed
to raw instructions in the validator, VADD and others could also be
done the same way.

If no one objects, I'll create them in the table gen files. It's not
important, just would be good to keep consistency (and easier to
generate IR).

2

There's no reason to have clang builtins for operations that can be represented directly. It just bloats the compiler. Please don't do that.

3

Ok, so why are some in there already? There is a validation pass (in a
pretty generic place, not ARM related: VMCore/AutoUpgrade.cpp) that
filters them out as plain instructions. Shouldn't them get removed as
well?

4

That code is to support reading old bitcode files containing intrinsics that no longer exist or that have different arguments/usage than in previous versions of llvm. It's not a validation pass, and it's not relevant to any new IR. It's only for backward compatibility.

5

Oh, I see. So we should also change ARMInstrNEON.td that still have
the intrinsic names on the definitions (ie. is still possible to
generate those intrinsics at all?).

6

The intrinsics that have been removed are no longer defined, so I don't see how ARMInstrNEON.td could be using them. I really don't know what you're referring to, though.

7

Hi Bob,

Example:

lib/VMCore/AutoUpgrade.cpp:91:

            Name.compare(14, 5, "vabal", 5) == 0) &&

lib/Target/ARM/ARMInstrNEON.td:3001:

defm VABALs : N3VLIntExtOp_QHS<0,1,0b0101,0, IIC_VABAD,
                                 "vabal", "s", int_arm_neon_vabds, zext, add>;

Isn't that "int_arm_neon_vabds" creating (or referring to) the intrinsic?

8

It's referring to the arm.neon.vabds intrinsic, which is different than the old vabal intrinsic.

9

Ok, sorry, those were the ones I was referring to: @llvm.arm.neon.* intrinsics.

Is it polluting too much to add the few last (llvm.arm.neon.vadd,
llvm.arm.neon.vsub)? It makes it a bit easier to generate neon
instructions in the front-end if everything is an LLVM intrinsic...

10

No, please don't add any more NEON intrinsics.

11

Ok, thanks.