search for: cgbuiltin

...g 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 ?llvm::Value* clang::CodeGen::CodeGenFunction::EmitAMDGPUBuiltinExpr(unsigned int, const clang::CallExpr*)?: /llvm-clang-trunk/src/tools/clang/lib/CodeGen/CGBuiltin.cpp:7283:39: error: *?r600_rsq? is not a member of ?llvm::Intrinsic?* return emitUnaryBuiltin(*this, E, I...

...claration(TheModule, Intrinsic::x86_sse2_psrl_dq); Result = Builder.CreateCall(F, ArrayRef<Value *>(&Ops[0], 2), "palignr"); And clang v3.9 migrated X86::BI__builtin_ia32_palignr128 like this https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CGBuiltin.cpp#L7629 just ignored the if (shiftVal < 32) condition? https://github.com/llvm-mirror/clang/blob/release_33/lib/CodeGen/CGBuiltin.cpp#L2642 Please give me some hint, thanks a lot! -- Regards, Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/

...ty], [IntrNoMem]>; } In src//tools/clang/include/clang/Basic/BuiltinsX86.def TARGET_BUILTIN(__builtin_x86_max_qb, "V2iV2iV2i", "ncV:64:", "") //I don't know the meaning of these parameters, just write according to the add function. In src/tools/clang/lib/CodeGen/CGBuiltin.cpp. in function EmitX86BuiltinExpr case X86::BI__builtin_x86_max_qb:{ return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::x86_max_qb)); } Then I do a simple test，just like this： #include <stdlib.h> #include <stdio.h> int main() { int a, b, c; a=1;b=2; c = int_x86_max_qb(a, b); } Whe...

...insic 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 recently. Do you know which change might have caused this? Thanks, Dounia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181230/ce58163d/attachment.html>

...%xmm0, -8(%rsp) >> movss -8(%rsp), %xmm0 >> >> Is this an optimization which is missing in llvm? > > Missing optimization. There isn't any reason to avoid inlining the > implementation. > > Probably the simplest place to implement this would be CGBuiltin in clang... It would also make sense to handle this in simplifylibcalls. There isn't anything C-specific about this. -Chris

...IUi", "n") +BUILTIN(__builtin_stack_pointer, "v*", "n") BUILTIN(__builtin_flt_rounds, "i", "nc") BUILTIN(__builtin_setjmp, "iv**", "j") BUILTIN(__builtin_longjmp, "vv**i", "r") diff --git a/lib/CodeGen/CGBuiltin.cpp b/lib/CodeGen/CGBuiltin.cpp index d187678..f66f506 100644 --- a/lib/CodeGen/CGBuiltin.cpp +++ b/lib/CodeGen/CGBuiltin.cpp @@ -736,6 +736,11 @@ RValue CodeGenFunction::EmitBuiltinExpr(const FunctionDecl *FD, Value *F = CGM.getIntrinsic(Intrinsic::frameaddress); return RValue::get(Build...

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

...now I'm considering clang out of scope, but being able to tell which target an intrinsic is for should also pretty easily clean it up too - other than a couple of references to ppc.altivec in CGExprScalar and a strange use of an x86 intrinsic in generic looking EH code, it's all confined to CGBuiltin.cpp and split up by target anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: intrinsics-generic-v-target.patch Type: text/x-patch Size: 13086 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160714/2c444164/attachme...

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 attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120417/3e2...

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

...      .cfi_startproc >         movq    %xmm0, -8(%rsp) >         movss   -8(%rsp), %xmm0 > > Is this an optimization which is missing in llvm? Missing optimization. There isn't any reason to avoid inlining the implementation. Probably the simplest place to implement this would be CGBuiltin in clang... -Eli

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>

...obably just an oversight. Please feel free to send in a patch fixing it. Ciao, Duncan. > > > I am trying to change all vector types (v2i16 and v4i8) in > include/llvm/IntrinsicsMips.td to i32, but I can't do that because the code in > CodeGenFunction::EmitBuiltinExpr (in clang/CGBuiltin.cpp) raises an assertion > when it calls Type::canLoslesslyBitCastTo to check whether conversion between > v2i16 (or v4i8) and i32 is legal. > > To work around this problem, I can put back CodeGenFunction::EmitMipsBuiltinExpr > which was removed in r159368 and add code to do type con...

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

...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 target's .td files. On the Clang side you'd add it to include/clang/Basic/BuiltinsXYZ.def and lib/CodeGen/CGBuiltin.cpp. Possibly lib/Sema/SemaChecking.cpp too if it has strange validity requirements. > 2.) Does the IR language have some kind of template support? > I'm not sure if this even possible - but I thought about having a template > function and when jitting the IR it could instantiate that...

...ch I think is lossless)? store i32 %src, i32* %ptr %ptr2 = bitcast i32* %ptr to v2i16* %dst = load v2i16* %ptr2 I am trying to change all vector types (v2i16 and v4i8) in include/llvm/IntrinsicsMips.td to i32, but I can't do that because the code in CodeGenFunction::EmitBuiltinExpr (in clang/CGBuiltin.cpp) raises an assertion when it calls Type::canLoslesslyBitCastTo to check whether conversion between v2i16 (or v4i8) and i32 is legal. To work around this problem, I can put back CodeGenFunction::EmitMipsBuiltinExpr which was removed in r159368 and add code to do type conversions, but I prefer n...

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

...to send in a patch fixing it. > > Ciao, Duncan. > > > > > > > I am trying to change all vector types (v2i16 and v4i8) in > > include/llvm/IntrinsicsMips.td to i32, but I can't do that because the > code in > > CodeGenFunction::EmitBuiltinExpr (in clang/CGBuiltin.cpp) raises an > assertion > > when it calls Type::canLoslesslyBitCastTo to check whether conversion > between > > v2i16 (or v4i8) and i32 is legal. > > > > To work around this problem, I can put back > CodeGenFunction::EmitMipsBuiltinExpr > > which was remove...