similar to: [LLVMdev] [PATCH] Addition to TableGen for dumping intrinsics as XML

At Thu, 15 Jul 2010 08:17:37 -0700, Peter Housel wrote: > The LLVM libraries provide the llvm::Intrinsic::getDeclaration() > function, which can provide a standard external declaration for any > of the (currently) 762 defined LLVM intrinsics, both for ordinary > intrinsics and for overrideable intrinsics with supplied parameter > types. Clients that do not link with the LLVM

After chatting on IRC, Peter wants a very specific interrupt (int4 on x86). I suggested he add a new llvm.x86.int(i32) intrinsic, and use the existing branch on llvm.sadd.with.overflow intrinsic. The x86 backend can then turn jo+int4 into into when reasonable. -Chris On Aug 9, 2010, at 5:45 PM, Chris Lattner wrote: > > On Aug 9, 2010, at 10:44 AM, Peter S. Housel wrote: > >>

The enclosed patch contains a number of wording and clarity improvements to BitCodeFormat.html, and documents in detail the record types used within MODULE blocks. I plan to continue documenting the rest of the record types, but I wanted to submit patches in reasonably-sized pieces. -Peter S. Housel- housel at acm.org -------------- next part -------------- A non-text attachment was scrubbed...

Is there any good reason for using DW_FORM_data1 for the DW_AT_language attribute of DW_TAG_compile_unit? This prevents using language codes in the DW_LANG_lo_user=0x8000 to DW_LANG_hi_user=0xffff range. I think the obvious change to use DW_FORM_data2 in line 1897 of lib/CodeGen/AsmPrinter/DwarfDebug.cpp should fix it. Or, if there are binary compatibility issues, the abbrev form could be chosen

Despite the commit of... ------------------------------------------------------------------------ r135371 | lattner | 2011-07-18 00:25:32 -0400 (Mon, 18 Jul 2011) | 2 lines untested patch to de-constify llvm::Type, patch by David Blaikie! current dragonegg svn at r135391 still fails to compile against FSF gcc 4.5.3 with the failure... In file included from

On Tue Nov 04 2014 at 12:43:05 PM Peter S. Housel <housel at acm.org> wrote: > On 11/04/2014 07:04 AM, Robinson, Paul wrote: > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sean Silva > >> > >> You haven't established that you really need this. AFAIK Apple's linker > >> doesn't need this

The enclosed patch adds a llvm.x86.int(i8) intrinsic expanding to the INT or INT3 instruction as appropriate. I haven't yet figured out the best way to select for the INTO instruction across basic blocks (hints would be welcome), but that can be added later with no changes in semantics. -Peter- On Aug 9, 2010, at 6:05 PM, Chris Lattner wrote: > After chatting on IRC, Peter wants a very

On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > The important point here is that the COFF MCSection needs to > have the right level of semantic information. In fact, > MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation > between TargetLoweringObjectFile ->

On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit

The enclosed patch adds documentation for the PARAMATTR_BLOCK, TYPE_BLOCK, and TYPE_SYMTAB_BLOCK records in the LLVM IR bitcode format. I have started documenting CONSTANTS_BLOCK and FUNCTION_BLOCK and will send patches when they are complete. -Peter- -------------- next part -------------- An HTML attachment was scrubbed... URL:

Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal with the

Ok, I've tracked down the problem I've had bootstrapping llvm-gcc. The culprit is in TreeToLLVM::EmitMemCpy: void TreeToLLVM::EmitMemCpy(Value *DestPtr, Value *SrcPtr, Value *Size, unsigned Align) { const Type *SBP = PointerType::get(Type::Int8Ty); const Type *IntPtr = TD.getIntPtrType(); Value *Ops[4] = { CastToType(Instruction::BitCast,

I want to create a vector version sqrt as the following. Value *Approx::CreateFSqrt(IRBuilder<> &builder, Value *v, const char* Name) { Type *tys[] = {v->getType()}; Module* M = currF->getParent(); Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd); CallInst *CI = builder.CreateCall(sqrtv, v, Name); return CI; } Here is Value *v is <2 x

Hello, This patch fixes bug 4882. Regards -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: pr4882.patch Type: application/octet-stream Size: 6856 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090907/266f900c/attachment.obj>

On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > > Thanks! Funny, I was just preparing a patch to submit for my changes to > MCSectionCOFF. My changes look to be fairly independent of yours, my change > was to deal with COMDAT's. I had dealt with the characteristics flags in the >

LLVMers, I am doing a CallGraphPass but would like to get the LoopInfo of the functions inside this pass, is this possible? Currently I have a function inside the CallGraph struct: void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<LoopInfo>(); AU.addPreserved<LoopInfo>(); } And later inside the pass I am calling: LoopInfo &LI =

On 11/10/11 11:48 AM, Ryan Taylor wrote: > John, > > Thanks, this does not compile though, I get this error: First, please CC the llvmdev list. That way, others having the same question can see the conversation, and others on the list can help correct any errors I make. :) > > cdfg_pass.cpp:511:11: error: ‘class llvm::Function’ has no member > named ‘getDeclaration’

Thanks, Shahid. It is fixed now. On Fri, Apr 17, 2015 at 8:50 PM, Shahid, Asghar-ahmad < Asghar-ahmad.Shahid at amd.com> wrote: > Hi zhi, > > > > You have to also pass the value type to getDecalaration() API such as > > > > Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd, > v->getType()); > > > > Regards, > >

John, This did not work. It compiles (isDeclaration was the name of the function) and I passed a reference (&F) (F is a function pointer). I still get the opt load error from the original message (UNREACHABLE exectuted!). Thanks. On Thu, Nov 10, 2011 at 10:00 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > 1. Ok will do. > 2. Ok, will do. > 3. It's a CallGraphPass. I

Hello. I come back to this thread. But I want to ask a slightly different question. Is there a way to have LLVM IR language intrinsics that are given at construction time a string that is written at assembly generation time as it is? (so, basically having placeholders of strings in LLVM that remain untouched until the end, including code generation time.) More exactly, I would