search for: cgbuiltins

After worked around the problem in SimplifyCFG.cpp (calling isCast() instead of comparing opcode), I hit another gcc crash for FunctionImport.cpp line 480, which I have no idea what's wrong with the code. "Luckily", I found gcc4.8.2 and gave it a try, both crashes are gone. *New problem though:* /llvm-clang-trunk/src/tools/clang/lib/CodeGen/CGBuiltin.cpp: In member function

Hi LLVM developers, After Remove int_x86_sse2_psll_dq_bs and int_x86_sse2_psrl_dq_bs intrinsics. The builtins aren't used by clang. https://reviews.llvm.org/rL229069 there was no Intrinsic::x86_sse2_psrl_dq any more, then how to migrate: Function *F = Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse2_psrl_dq); Result = Builder.CreateCall(F,

Hi Everyone！ I am a newbie at llvm. So the question may be fundamental but difficult to me. I want to add an trinsics in x86 and make the following changes.I want that max_qb can find the max of two Integers and return it. In src/include/llvm/IR/Intrinsics.td : let TargetPrefix = "x86" in { def int_x86_max_qb: GCCBuiltin<"__builtin_x86_max_qb">,

Hello, I was implementing the llvm_any_type in my intrinsic def int_csa_xxx : Intrinsic<[llvm_any_ty], [llvm_i32_ty]>; as the following in its corresponding builtins in Builtins.def: BUILTIN(__builtin_xxx, "v.", "nt") the "t" was sufficient here to not perform any type checking. The type checking was handled in CGBuiltin.cpp. This was working until

On Apr 27, 2012, at 2:02 PM, Eli Friedman wrote: > On Fri, Apr 27, 2012 at 12:09 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: >> while gcc does it in two move instructions: >> >> $ gcc foo1.c -S -o -O3 >> foo1: >> .LFB0: >> .cfi_startproc >> movq %xmm0, -8(%rsp) >> movss -8(%rsp), %xmm0 >> >>

One of the issues the LLVMLinux project is having is with the use of named registers in the Linux kernel code. The kernel uses something like this in order to assign a C variable name to a register (one for each kernel arch). register unsigned long current_stack_pointer asm("esp"); clang doesn't allow this kind of thing which required a patch which less efficient: #define

This patch adds EmitTypeAuxAttribute() function to CGDebugInfo, which allows other parts of clang issue auxiliary information through an enumeration type in Dwarf information. For example, by calling DI->EmitTypeAuxAttribute(type, "ID", 1234); We can get following information in dwarf: <1><3f>: Abbrev Number: 3 (DW_TAG_structure_type) <40> DW_AT_name

There are a few places in llvm's generic codegen that refer to target specific intrinsics. This is bad layering and we shouldn't do it. It also means that if we don't build a target we still have to support all of it's intrinsics and other such annoyances. The main violator of this is InstCombineCalls - I'd like to push this into the targets, and just have a case that says

Sure this is more likely a gcc bug. However, same toolchain compiled without any problems a week ago. Also, in some organizations, upgrading gcc is very hard if not impossible. On Fri, Jul 22, 2016 at 11:11 AM, Paulo Matos via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 22/07/16 20:08, Welson Sun via llvm-dev wrote: > > This is gcc4.8.0 compiling HEAD synced on

Hi, Is "__builtin_malloc" function supported in LLVM...? I checked in "tools/clang/include/clang/ > > Basic/Builtins.def", > "tools/clang/lib/CodeGen/CGBuiltin.cpp" and couldn't find the > implementation. > Could anyone please comment about it. > > Thanks in advance, > Viswa > > -------------- next part -------------- An HTML

When I compile this code which includes call to crealf, $ cat foo1.c #include <complex.h> float foo1(complex float z) { return crealf(z); } clang emits a call to crealf, $ clang foo1.c -S -o - -O3 foo1: # @foo1 .cfi_startproc # BB#0: # %entry jmp crealf # TAILCALL while gcc does it in two move

On Fri, Apr 27, 2012 at 12:09 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > When I compile this code which includes call to crealf, > > $ cat foo1.c > #include <complex.h> > > float foo1(complex float z) { return crealf(z); } > > clang emits a call to crealf, > > $ clang  foo1.c -S -o - -O3 > foo1:                                   # @foo1 >

I want to write a simple backend-specific instrinsic that will just call an instruction. How should I do that? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180924/7faeeb3d/attachment.html>

Hi Akira, > This is the definition of BITCAST in include/llvm/CodeGen/ISDOpcodes.h: > > // BITCAST - This operator converts between integer, vector and FP > // values, as if the value was stored to memory with one type and loaded > // from the same address with the other type (or equivalently for vector > // format conversions, etc). The source and result are required to have

...t gcc also implements, but that's not a requirement. If you add a builtin with the same name to the builtin file in clang's include/clang/Basic/Builtins*.def then they will find each other. You can also just add a builtin to clang's builtin file and catch it in clang's lib/CodeGen/CGBuiltins.cpp and implement whatever IR you want including calling an intrinsic. Hope this helps. On Tue, May 24, 2016 at 5:04 PM, Rail Shafigulin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I've created an intrinsic from my target, but I can't figure out how I can > run it fro...

Hi Björn, On 9 April 2018 at 09:43, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 1.) Can I teach the LLVM new platform depended intrinsics? > Like I provide assembly code and want to create a custom intrinsic for it. Yes. You'd add a declaration to include/llvm/IR/IntrinsicsXYZ.td (where XYZ is your target), and then you can select them with a normal pattern in your

This is the definition of BITCAST in include/llvm/CodeGen/ISDOpcodes.h: // BITCAST - This operator converts between integer, vector and FP // values, as if the value was stored to memory with one type and loaded // from the same address with the other type (or equivalently for vector // format conversions, etc). The source and result are required to have // the same bit size (e.g. f32 <->

I've created an intrinsic from my target, but I can't figure out how I can run it from a C code. Most of the targets have a GCCBuiltin and it looks like it is the way to execute an intrinsic from C code. However in my case there is no actual GCC built in. Any help on this is really appreciated. -- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part

Type::canLoslesslyBitCastTo(Type *Ty) in lib/VMCore/Type.cpp always returns false when it checks whether an integer can be bitcast to a vector or vice versa. For example, (i32 => v2i16) or (v2i16 => i32) is false. But it seems that it returns true if it is checking conversion between two vector types which have the same size. For example, (v4i8 => v2i16) would return true. What is the

Hi Duncan and llvm developers, The attached patch makes the function return true if the conversion is between a vector and an integer of the same size. Please review when you have time. On Tue, Jul 10, 2012 at 12:21 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Akira, > > > This is the definition of BITCAST in include/llvm/CodeGen/ISDOpcodes.h: > > > > //