similar to: [LLVMdev] llvm builtins

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

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.

Dear all, During app compilation we have a crash in NVPTX backend: LLVM ERROR: Cannot select: 0x732b270: i64 = ExternalSymbol'__powisf2' [ID=18] As I understand LLVM tries to lower the following call %28 = call ptx_device float @llvm.powi.f32(float 2.000000e+00, i32 %8) nounwind readonly to device intrinsic. The table llvm/IntrinsicsNVVM.td does not contain such intrinsic, however it

On Fri, Jan 30, 2015 at 10:37 PM, reed kotler <rkotler at mips.com> wrote: > Ok. > > I'm basically just following the model of the other fast-isel ports. > Yeah, not your fault - just an architectural quirk. It's possible we could workaround the debug info side of this by declaring the virtual dtor (or some other virtual function - even an explicit anchor as we have

(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. In any case, the reason this produces the debugging experience you're seeing is that LLVM (& GCC, for that matter) assumes that if your class

Hi, we have two modules, one that we basically use as a library in which we store a lot of simple function calls, the other is small program generated at run-time. Whenever a function call for to one of the builtin functions is being called we use CloneFunction to clone the instruction from the library module and insert it in the generated module. The problem is for example when we have

Hello, The purpose of the llvm.powi intrinsic isn't clear to me. Why is llvm.powi preferable to multiplication and division for small constant powers (e.g., 1/x, x*x, etc.)? Why is it preferable to llvm.pow for large variable powers? I'm also curious about the time bound. I'm assuming that powi(x,1000000) doesn't do a million multiplications... Do any architectures have

Dear all, I'm using IntrinsicLowering class to remove all intrinsics in LLVM byte-code. Unfortunately, I meet several problems: 1. Why I can not get the type of CallInst *CI? !CI->getType()->isVoidTy() is not working and how to solve it? This type information has some impacts with intrinsics such as flt_rounds. 2. Why Intrinsic::vastart and Intrinsic::powi are excluded from

> On Jan 12, 2017, at 12:58 PM, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/12/2017 9:33 AM, Mehdi Amini via llvm-dev wrote: >>> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Mon, 9 Jan 2017 11:43:17 -0600 >>> Wei Ding via llvm-dev <llvm-dev at

Hello, all. To get my feet wet and hopefully make a small contribution, I was looking for something small to start with. I settled on one of the suggestions from the CodeGen readme: > Reassociate should turn things like: > > int factorial(int X) { > return X*X*X*X*X*X*X*X; > } > > into llvm.powi calls, allowing the code generator to > produce balanced multiplication

I was looking through the InstCombine pass, and I was wondering why signed division is not considered a valid operation to combine in the canEvaluateTruncated function. This means, given the following code: %conv = sext i16 %0 to i32 %conv1 = sext i16 %1 to i32 %div = sdiv i32 %conv, %conv1 %conv2 = trunc i32 %div to i16 * Assume %0 and %1 are registers created from simple 16-bit loads. We

Hi all, I have been looking at the way LLVM optimizes code before forwarding it to the backend I develop for my company and while building define i32 @test_extract_subreg_func(i32 %x, i32 %y) #0 { entry: %conv = zext i32 %x to i64 %conv1 = zext i32 %y to i64 %mul = mul nuw i64 %conv1, %conv %shr = lshr i64 %mul, 32 %xor = xor i64 %shr, %mul %conv2 = trunc i64 %xor to i32

Hi, It looks like SimplifyLibCalls has a tendency to emit calls to libm functions without checking with TLI whether these calls are available. For example, PowOpt has this code: struct PowOpt : public UnsafeFPLibCallOptimization { PowOpt(bool UnsafeFPShrink) : UnsafeFPLibCallOptimization(UnsafeFPShrink) {} virtual Value *callOptimizer(Function *Callee, CallInst *CI, IRBuilder<> &B)

Hi Hao Shen, > 1. Why I can not get the type of CallInst *CI? > !CI->getType()->isVoidTy() is not working and how to solve it? what does "not working" mean? It should work. > 2. Why Intrinsic::vastart and Intrinsic::powi are excluded from > IntrinsicLowering function? > There are no way to lower them at the byte-code level? For vastart, it probably isn't

Dear list, I have to read a not-so-small bunch of not-so-small Excel files, which seem to have traversed Window 3.1, Windows95 and Windows NT versions of the thing (with maybe a Mac or two thrown in for good measure...). The problem is that 1) I need to read strings, and 2) those strings may have various encodings. In the same sheet of the same file, some cells may be latin1, some

Hi, I wonder what is the right way to target an old glibc? I have a machine which is up to date (glibc 2.32 and clang+lld 10.0.1). So far I've been able to target older glibc by having a C file containing: __asm__(".symver powf,powf at GLIBC_2.2.5"); __asm__(".symver expf,expf at GLIBC_2.2.5"); __asm__(".symver exp2f,exp2f at GLIBC_2.2.5");

> On Jan 12, 2017, at 2:21 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Jan 12, 2017, at 11:04 AM, Steve (Numerics) Canon <scanon at apple.com <mailto:scanon at apple.com>> wrote: >> >>> >>> On Jan 12, 2017, at 12:58 PM, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

On Tue, Nov 10, 2020 at 7:01 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > How to find what is pulling libmvec? > > If you build a -DCMAKE_BUILD_TYPE=Debug lld, you can set a breakpoint > on lld/ELF/MarkLive.cpp:114 (ss->getFile().isNeeded) and check which > symbol makes > libmvec.so needed. I'm afraid this is going to far for me :) > > On the other

On Wed, Oct 28, 2020 at 6:07 PM Fangrui Song <maskray at google.com> wrote: > > On 2020-10-28, Alexandre Bique via llvm-dev wrote: > >Hi, > > > >I wonder what is the right way to target an old glibc? > > > >I have a machine which is up to date (glibc 2.32 and clang+lld 10.0.1). > > > >So far I've been able to target older glibc by having a

Hello, For this C code: int func(int foo, char bar) { int result = foo + bar; if (foo > bar) result += 100 - foo; else result += 221 - bar; return result; } Compiled with -O0 -g, the following IR represents the relevant parts of the if/else statement: %0 = load i32* %foo.addr, align 4, !dbg !49 %1 = load i8* %bar.addr, align 1, !dbg !49 %conv = sext