similar to: [LLVMdev] getIntrinsicID() optimization, mark 2

It is possible to change the name of a Function with Value::setName, so this patch _could_ cause incorrect answers. You should add 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

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

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.

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 work for the code I

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

On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com> wrote: >>> It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry. >> >> I tried doing that a few years ago. It’s not nearly as easy as it sounds because we’ve got hardcoded references to various target intrinsics scattered

> On Dec 23, 2014, at 10:54 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > >> On Dec 23, 2014, at 10:41 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote: >> >> On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>>>> It should be

On 21 September 2010 20:30, Bob Wilson <bob.wilson at apple.com> wrote: > 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. Hi Bob, Example: lib/VMCore/AutoUpgrade.cpp:91: Name.compare(14, 5, "vabal", 5) == 0) &&

_mulx_u64 only exists when the target is x86_64. That's still not very portable. I'm not opposed to removing the bmi2 check, but gcc also has the same check so it doesn't improve portability much. ~Craig On Sat, Dec 29, 2018 at 4:44 PM Arthur O'Dwyer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Pawel, > > There is the _mulx_u64 intrinsic, but it

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

Hi, For some maybe dumb reasons I try to write a portable version of int128. What is very valuable for this implementation is access to MUL instruction on x86 which provides full 64 x 64 -> 128 bit multiplication. An equally useful on ARM would be UMULH instruction. Well, the way you can access this on clang / GCC is to use __int128 type or use inline assembly. MSVC provides an intrinsic for

When trying to display and do anything with a variable of type IntrinsicInst, gdb thinks that it's an incomplete type and kind find any member functions or even display the class. (gdb) list 1337 1332 1333 // Finish off the call including any return values. 1334 return finishCall(CLI, RetVT, NumBytes); 1335 } 1336 1337 bool MipsFastISel::fastLowerIntrinsicCall(const

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

Ok. I'm basically just following the model of the other fast-isel ports. On 01/30/2015 09:12 PM, David Blaikie wrote: > (I'm assuming you're building LLVM with clang, in this case?) > > Looks like IntrinsicInst is one of those "lies" in LLVM that works via > type punning that's undefined behavior in C++, so it's code that > should be fixed anyway.

Hi! Attached patches split init.trampoline into adjust.trampoline and init.trampoline, like in gcc. As mentioned in the previous mail, I've not made a documentation patch, since I'm not sure about what the documented semantics of llvm.adjust.trampoline should be. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was

On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi Chris, > > It's not broken, but the performance is crippled. > > I noticed that the code still contains some MMX instructions, but several > operations get expanded (apparently swizzling and such get expanded to a > large number of byte moves). I think some changes related to

Hi Nicolas, > I guess that's because the value of the last argument of llvm.memcpy has > to be known at compile time. Hmmm ok, that's understandable, but it's also a bit of a problem for me. I am writing a pass that creates a 'shadow' copy of each function, so that I can do some bookkeeping with it, and then call the original function afterwards. This would include

Hi all, Please consider committing the attached patch. I believe the SSE2 packsswb, packssdw and packuswb intrinsics have an incorrect return type. Thanks, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090609/85ed0b5e/attachment.html> -------------- next part -------------- A

Hi all, I'd like to be able to write JIT-compiled code to a Windows DLL. I have no idea where to start though. Does LLVM already offer some support for this? Or would it be straightforward to write my own DLL writer (no advanced features needed)? Or maybe I could use an external linker? All help highly appreciated! Cheers, Nicolas -------------- next part -------------- An HTML