search for: vabals

...defined, so I don't see how ARMInstrNEON.td could be using them.  I really don't know what you're referring to, though. 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? -- cheers, --renato http://systemcall.org/ Reclaim you...

...sing them. I really don't know what you're referring to, though. > > 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? It's referring to the arm.neon.vab...

On 21 September 2010 20:02, Bob Wilson <bob.wilson at apple.com> wrote: > 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. Oh, I see. So we should also

On Sep 21, 2010, at 12:28 PM, Renato Golin wrote: > On 21 September 2010 20:02, Bob Wilson <bob.wilson at apple.com> wrote: >> 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

On 21 September 2010 21:16, Bob Wilson <bob.wilson at apple.com> wrote: > It's referring to the arm.neon.vabds intrinsic, which is different than the old vabal intrinsic. 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

...long series of if (Len == 16 && !memcmp(Name, "llvm.alpha.umulh", 16)) return Intrinsic::alpha_umulh; if (Len > 15 && !memcmp(Name, "llvm.annotation.", 16)) return Intrinsic::annotation; if (Len > 20 && !memcmp(Name, "llvm.arm.neon.vabals.", 21)) return Intrinsic::arm_neon_vabals; ... There has to be a more efficient way to do this. If nothing else, the first 6 characters of that memcmp are always equal, and for groups of intrinsics like llvm.arm.neon.v*, a trie-like search would be better. llvm/ADT/Trie.h doesn't quite do...

Any takers? This patch improves on the previous one by making getIntrinsicID() inline. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091017/9406e0ad/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: FastIntrinsicID-2.patch Type:

...long series of if (Len == 16 && !memcmp(Name, "llvm.alpha.umulh", 16)) return Intrinsic::alpha_umulh; if (Len > 15 && !memcmp(Name, "llvm.annotation.", 16)) return Intrinsic::annotation; if (Len > 20 && !memcmp(Name, "llvm.arm.neon.vabals.", 21)) return Intrinsic::arm_neon_vabals; ... There has to be a more efficient way to do this. If nothing else, the first 6 characters of that memcmp are always equal, and for groups of intrinsics like llvm.arm.neon.v*, a trie-like search would be better. llvm/ADT/Trie.h doesn't quite do...

On Sep 21, 2010, at 1:31 PM, Renato Golin wrote: > On 21 September 2010 21:16, Bob Wilson <bob.wilson at apple.com> wrote: >> It's referring to the arm.neon.vabds intrinsic, which is different than the old vabal intrinsic. > > Ok, sorry, those were the ones I was referring to: @llvm.arm.neon.* intrinsics. > > Is it polluting too much to add the few last