similar to: Need help in understanding llvm optimization

I am sorry to not make my question clear. My question is how this value is calculated without having fadd and fsub in IR? On Sat, Aug 11, 2018 at 4:06 PM, Craig Topper <craig.topper at gmail.com> wrote: > Neither 1e16 or 1e16+1 can be accurately represented in a double. The > largest integer than be accurately represented is 2^53. As the number gets > larger floating sacrifices

Hello All, I am instrumenting IR to pass addres of the function to runtime but I am getting error - Instruction does not dominate all uses. I used M.dump() to get below dump, not able to figure out what I am doing wrong. Any help would be much appreciated. define dso_local double @mysqrt(double %val1) local_unnamed_addr #0 { entry: %0 = bitcast double (double)* @mysqrt to i8* %1 = call

This is of course not homework. I am trying to understand how fast math optimizations work in llvm. When I compared IR for both the programs, the only thing I have noticed is that fdiv and fmul are replaced with fdiv fast and fmul fast. Not sure what happens in fdiv fast and fmul fast. I feel that its because d/max is really small number and fast-math does not care about small numbers and consider

Hi Devs, going by this link https://llvm.org/docs/LangRef.html#floatenv it says that floating point operation does not have side effects by defaults. but when compile a test case i.e. cat a.c float foo(float a, float b) { return a+b; } $clang a.c -O2 -S -emit-llvm emit ir like: $cat a.ll --------------------------------------- ; ModuleID = 'a.c' source_filename = "a.c" target

Hello, I have followed steps given in - https://stackoverflow.com/questions/29910051/integrating-llvm-passes/48142693#48142693 <https://stackoverflow.com/questions/29910051/integrating-llvm-passes/48142693#48142693>, to integrate my pass with pass manager and run it with clang. I am able to run my pass with opt - opt -mypass but when I try to run it with clang, I always get an error -

For the following C code __fp16 x, y, z, w; void foo() { x = y + z; x = x + w; } clang produces IR that extends each operand to float and then truncates to half before assigning to x. Like this define dso_local void @foo() #0 !dbg !18 { %1 = load half, half* @y, align 2, !dbg !21 %2 = fpext half %1 to float, !dbg !21 %3 = load half, half* @z, align 2, !dbg !22 %4 = fpext half %3 to float, !dbg

Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under

Hi Devs, I am looking at the bug https://bugs.llvm.org/show_bug.cgi?id=43953 and found that following piece of ir %arrayidx = getelementptr inbounds float, float* %Vec0, i64 %idxprom %0 = load float, float* %arrayidx, align 4, !tbaa !2 %arrayidx2 = getelementptr inbounds float, float* %Vec1, i64 %idxprom %1 = load float, float* %arrayidx2, align 4, !tbaa !2 %sub = fsub fast float %0, %1

(though, usual caveat: you /usually/ shouldn't be doing that - instead relying only on whatever semantics the IR actually carries, rather than implying extra semantics based on the demangled name) On Wed, Jun 24, 2020 at 12:48 PM Johannes Doerfert via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I have not tried it but maybe > > `std::string llvm::demangle(const

Hello, LLVM IR flattens out the structure with one integer element to i32. Is there any way to disable this? I want to preserve the type information of the structure. I tried compiling the program with O0, it maintains the type for most of the instructions but for all. Regards, Sangeeta -------------- next part -------------- An HTML attachment was scrubbed... URL:

Are you able to send any IR for others to reproduce this issue? On Wed, Jul 17, 2013 at 11:23 PM, Peter Newman <peter at uformia.com> wrote: > Unfortunately, this doesn't appear to be the bug I'm hitting. I applied > the fix to my source and it didn't make a difference. > > Also further testing found me getting the same behavior with other SIMD > instructions.

Thanks Eli. I forgot to bring up the strict FP questions which I was working on when I found this. If we're in a strict FP function, do the fp_to_f16/f16_to_fp emitted by promoting load/store/bitcast need to be strict versions of fp_to_f16/f16_to_fp. And if so where do we get the chain, especially for the bitcast case which isn't a chained node. ~Craig On Tue, Dec 10, 2019 at 3:18 PM

Unfortunately, this doesn't appear to be the bug I'm hitting. I applied the fix to my source and it didn't make a difference. Also further testing found me getting the same behavior with other SIMD instructions. The common factor is in each case, ECX is set to 0x7fffffff, and it's an operation using xmm ptr ecx+offset . Additionally, turning the optimization level passed to

Hello, I am doing some program analysis with C++ programs. I need to check if some particular function is called in the program, for that I need the name of the function being called in the call instruction. Since C++ mangles the name of the function, I need a way to demangle the function name in llvm IR. Is there any way to achieve that in llvm pass? Regards, Sangeeta -------------- next part

Hello, I am working on creating a llvm pass which clones a certain function with a different name using CloneFunctionInto. I create a call instruction to call a new cloned function from the old function. In llvm IR and in .s file everything looks as expected, but when I call this program with gdb and set a breakpoint on this new function, gdb shows the name of the original function. I know it has

Do you pull clang under llvm/tools and compile it as well? In theory, if `opt` recognize the option, so does `clang -mllvm`. 2018-01-12 8:47 GMT+08:00 sangeeta chowdhary <sangitachowdhary at gmail.com>: > Hello, > > I have tried giving this option like this > > clang -c -emit-llvm -mllvm -rdetector hello.c -c -o hello.bc > but I am getting error " Unknown command

looks like experimental/work in progress support: https://reviews.llvm.org/D62731 On Tue, May 26, 2020 at 10:39 PM kamlesh kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Wed, May 27, 2020 at 11:06 AM kamlesh kumar <kamleshbhalui at gmail.com> > wrote: > >> Hi Devs, >> going by this link https://llvm.org/docs/LangRef.html#floatenv >>

Hi, I’ve been investigating https://bugs.llvm.org/show_bug.cgi?id=43374, which is about clang/llvm producing code that triggers a floating point exception when x is NaN, when targeting ARM, in the below code example. int bar(float x) { return x!=x ? 0 : 1; } The C99 standard states in section 7.12.14: """ The relational and equality operators support the usual mathematical

I have taken SimplePass and added in Transform directory, “libLLVMSimplePass.a” is built but I can not see this pass in opt —help. I don’t even see the name of pass while registering it in the example. > On Jan 13, 2018, at 7:35 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > On 13 Jan 2018, at 03:45, Craig Topper via llvm-dev <llvm-dev at lists.llvm.org>

So I've been narrowing down a very fun issue in our Burst compiler stack with respect to noalias support, and I've managed to basically boil this down to the following failure (see https://godbolt.org/z/-mdjPV): int called(int* __restrict__ a, int* b, int* c) { return *a + *b + *c; } int foo(int * x, int * y) { return *x + *y + called(x, x, y); } int bar(int * x, int * y) { return