search for: intrinsicid

Hi Chris, Function is currently 108 bytes large. Could 4 more bytes really be an issue? Actually 2 should suffice. While I understand that some applications value storage more than anything, many applications value compilation time very highly. getIntrinsicID is called all over the place (isIntrinsic uses it as well), and every single time it checks the function name. To me that sounds a lot more dramatic than 2 bytes. Anyway, using SubclassData could work. It's already being used for the calling convention, which has values ranging from 0 to 68...

TLDR: Figuring out whether a declaration is a TLI LibFunc is slow.  We hammer that path in CGP.  I'm proposing storing the ID of a TLI LibFunc in the same IntID field in Function we use for IntrinsicID to make that fast. Looking into a compile time issue during codegen (LLC) for a large IR file, I came across something interesting.  Due to the presence of a very large number of intrinsics in the particular example, we were spending almost 30% of time in CodeGenPrep::optimizeCallInst, and within...

Hi Jeffrey, Please correct me if I'm wrong, but I believe a test that checks for the old behavior would be pointless. I realize that my patch would return an unmatching intrinsicID when the function's name changes, but the real question we should ask is do we really want to be able to change the intrinsicID by changing the function's name? Also, the original Function constructor contains this code: // Ensure intrinsics have the right parameter attributes. if (unsign...

...e are a number of ways we could work toward something like this. I’m completely in favor of a world where Intrinsics are properties of the targets and don’t leach out, however today they do in a lot of places. What are the specific problems here? Anything that does an equality comparison with the IntrinsicID can be changed to do strcmp with the name. That would handle the one-off cases like InstCombiner::SimplifyDemandedUseBits in InstCombine. The other cases in InstCombine could be handled similarly, but may be better handled by adding a intrinsic behavior query APIs to the intrinsic registry, or wo...

On Oct 16, 2009, at 5:50 AM, Nicolas Capens wrote: > Hi all, > > While profiling I discovered that the Function::getIntrinsicID() > method is called a lot, and every time it uses string comparison to > recompute the ID number. As far as I know the name of an intrinsic > function doesn’t change, so the ID could be determined just once at > Function construction time. > > I’ve attached a patch that d...

...dd a test that calls setName("intrinsic.name") to make sure this keeps working, regardless of where this patch goes. You might be able to catch such events in the ValueSymbolTable and update the intrinsic ID, but I can't find an obvious place to put that code. I also noticed that getIntrinsicID (implemented in Intrinsics.gen) is a switch statement on the first letter of the intrinsic name plus a long series of if (Len == 16 && !memcmp(Name, "llvm.alpha.umulh", 16)) return Intrinsic::alpha_umulh; if (Len > 15 && !memcmp(Name, "llvm.annotation.&quot...

Hi all, While profiling I discovered that the Function::getIntrinsicID() method is called a lot, and every time it uses string comparison to recompute the ID number. As far as I know the name of an intrinsic function doesn't change, so the ID could be determined just once at Function construction time. I've attached a patch that does this and it appears to...

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:...

Is there a "standard" way to check for a lock acquire and release for a transformation pass? Assuming the locks aren't inline asm, so llvm-gcc can compile __sync_lock_test_and_set builtin to llvm.atomic.swap, one could potentially look for IntrinsicInst with the appropriate IntrinsicID. But there's many ways to acquire a lock just using the atomic builtins [1] -- not to mention how a lock implements a blocking acquire. The lock release could use __sync_lock_release, which is converted into a regular function call of appropriate size, or the lock could just do a plain write o...

On Wed, 2 Jan 2008, Chris Lattner wrote: >This should be fixed now, please verify, thanks! > >-Chris The newer code that TableGen produces is indeed lower however, MSVC still throws the same error messages (and moreover, I don't think they're fixing it anytime soon.. I'll try to re-open this issue to them). Also, it seems that the new code produces an extraneous "if

...ways we could work toward something like this. I’m completely in favor of a world where Intrinsics are properties of the targets and don’t leach out, however today they do in a lot of places. >> >> What are the specific problems here? Anything that does an equality comparison with the IntrinsicID can be changed to do strcmp with the name. That would handle the one-off cases like InstCombiner::SimplifyDemandedUseBits in InstCombine. >> >> The other cases in InstCombine could be handled similarly, but may be better handled by adding a intrinsic behavior query APIs to the intrins...

Julien Schmitt wrote: > I would like to use intrinsic with different address space. > I defined an intrinsic (used to represent à specific instruction of my target) with a pointer in its arguments, but when calling this intrinsic, if the pointer is not in the generic address space (ie AddrSpace 0), an error occurs ("bad signature"). > > How can I specify the address space in

I would like to use intrinsic with different address space. I defined an intrinsic (used to represent à specific instruction of my target) with a pointer in its arguments, but when calling this intrinsic, if the pointer is not in the generic address space (ie AddrSpace 0), an error occurs ("bad signature"). How can I specify the address space in the intrinsic definition ? Thank you.

...t benefits are an 11% reduction in size for libLLVMCore, which is mostly due to Function.cpp.o reducing in size by 300KB (almost 39%). The biggest thing in there that would contribute to actual code size is the almost 28,000 line switch statement that provides the implementation for Function::lookupIntrinsicID. > > That makes sense. It sounds like there is a better design here: we should move to a model where intrinsic tables are registered by any targets that are activated. That would allow the intrinsic tables (including these switch/lookup mapping tables) to be in the target that uses them. &...

...+ if (isVolatile) + DAG.setRoot(S.getValue(0)); + else + PendingLoads.push_back(S.getValue(0)); } + /// IntrinsicCannotAccessMemory - Return true if the specified intrinsic cannot /// access memory and has no other side effects at all. static bool IntrinsicCannotAccessMemory(unsigned IntrinsicID) { @@ -3987,7 +4159,7 @@ void SelectionDAGISel::BuildSelectionDAG(SelectionDAG &DAG, BasicBlock *LLVMBB, std::vector<std::pair<MachineInstr*, unsigned> > &PHINodesToUpdate, FunctionLoweringInfo &FuncInfo) { - SelectionDAGLo...

...C_WO_CHAIN(Op, DAG); > + case ISD::SELECT_CC: return LowerSELECT_CC(Op, DAG); > + case ISD::UDIVREM: return LowerUDIVREM(Op, DAG); > + } > +} > + > +SDValue AMDGPUTargetLowering::LowerINTRINSIC_WO_CHAIN(SDValue Op, > + SelectionDAG &DAG) const > +{ > + unsigned IntrinsicID = cast<ConstantSDNode>(Op.getOperand(0))->getZExtValue(); > + DebugLoc DL = Op.getDebugLoc(); > + EVT VT = Op.getValueType(); > + > + switch (IntrinsicID) { > + default: return Op; > + case AMDGPUIntrinsic::AMDIL_abs: > + return LowerIntrinsicIABS(Op, DAG...