similar to: Signed Div SCEVs

Hi, The call graphs generated by "*llvm-xray graph*" has function names, while the "*llvm-xray graph-diff*" doesn't shows function names. This is the command I am using llvm-xray graph-diff xray-log.clang.1 xray-log.clang.2 -instr-map=../xray-build/bin/clang -o diff.dot Attached is the portion of the generated diff graph. Am I missing any flag? [image: graph_diff.jpg]

Ugh, that would be a “yes” then… -- Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> AI tools development From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Krzysztof Parzyszek via llvm-dev Sent: Friday, September 27, 2019 10:05 AM To: Dangeti Tharun kumar <cs15mtech11002 at iith.ac.in>; llvm-dev at lists.llvm.org Subject: [EXT] Re:

Hi, In "target-features" list in LLVM-IR, there are "+feature", "-feature". My question is, does "-feature" is equivalent to not specifying a feature at all? For example: *attributes #0 = { "target-cpu"="znver2" "target-features"="+avx -avx2" }* Wheather it is equalent to omitting the avx2 from list? *attributes #0

Hi Dean, I have tried with -instr-map-1 and -instr-map-2, it didn't work. Is there a way to find the function name from the identifier? -DTharun On Mon, Jan 7, 2019 at 2:29 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > Hi Dangeti, > > That's interesting -- can you try providing both `-instr-map-1=` and > `-instr-map-2=` even though they're the same

Hi, I have a doubt regarding *getAnalysisUsage.* My assumption is that, as analysis passes will not change the IR, all the passes required by an analysis pass should be preserved. Say, I have an analysis pass which requires another analysis pass called *SomeAnalysis* and I have not added *AU.addPreserved<SomeAnalysis>() *to my pass. Would the pass manager still considers the *SomeAnlaysis

On Mon, Jan 7, 2019 at 3:21 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > On Mon, Jan 7, 2019 at 8:43 PM Dangeti Tharun kumar > <cs15mtech11002 at iith.ac.in> wrote: > > > > Hi Dean, > > > > I have tried with -instr-map-1 and -instr-map-2, it didn't work. > > > > Yeah, I'm looking through the code and it looks like

On Fri, Nov 2, 2018 at 3:31 PM Anton Korobeynikov <anton at korobeynikov.info> wrote: > > Yes, I am compiling for linux system. > > So the RA will not consider assigning a scratch register to a live range > crossing function call, though it may reduce spills? > Well, it has to spill the register – otherwise it could be clobbered by a > call. May be, I haven't

Hi On Tue, Oct 30, 2018 at 10:47 PM Matthias Braun <mbraun at apple.com> wrote: > At a first glance I see nothing obviously wrong with the assembly, but it > is a big file. So if you have a specific part in mind, please copy into the > E-Mail discussion. > > I assume you are compiling for a mac or linux system? In that case none of > the xmm registers are callee saved (as

Dear LLVM Community, I am D Tharun Kumar, masters student at Indian Institute of Technology Hyderabad, working in a team to improve current vectorizer in LLVM. As an initial study, we are studying various benchmarks to analyze and compare vectorizing capabilities of LLVM, GCC and ICC. We found that vectorization remarks given by LLVM are vague and brief, comparatively GCC and ICC are giving

Hi Dangeti, Ramakrishna, Adam, and Gerolf, >Yes this is an area that needs further improvement. We have some immediate plans to make these more useful. See the recent llvm-dev threads [1], [2]. It takes a lot of dedicated effort to make vectorization report easier to understand by ordinary programmers (i.e., those who are not compiler writers). Having done that for ICC ourselves, we truly

Hello, I have studied register allocation in theoretical aspects and exploring the same in the implementation level. I need a minimal testcase for register spilling to analyze spilling procedure in llvm. I tried with a testcase taking 20 variables but all the 20 variables are getting stored in the stack using %rbp. Maybe my live variable analysis is wrong. Please help me with a minimal testcase

> On Oct 10, 2016, at 2:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > From: "Dangeti Tharun kumar via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > To: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > Cc: "Santanu Das" <cs15mtech11018 at iith.ac.in <mailto:cs15mtech11018 at

Dear community, Our team at IITH have been experimenting with loop-distribution pass in LLVM. We see the following results on few benchmarks. clang -O3 -mllvm -enable-loop-distribute -Rpass=loop-distribute file.c clang -O3 -mllvm -enable-loop-distribute -Rpass-analysis=loop-distribute file.c TORCH

add object rules so that the division, remainder and friends get really build on sparc, patch from Fabio M. Di Nitto <fabbione@ubuntu.com>. reworked to apply on latest git tree. Signed-off-by: maximilian attems <maks@sternwelten.at> --- Has been since long in the Debian and Ubuntu klibc. diff --git a/klibc/arch/sparc/Makefile.inc b/klibc/arch/sparc/Makefile.inc index

Hi, I’d like to propose to extend LLVM IR intrinsics set, adding new ones for safe-division. There are intrinsics for detecting overflow errors, like sadd.with.overflow, and the intrinsics I’m proposing will augment this set. The new intrinsics will return a structure with two elements according to the following rules: safe.[us]div(x,0) = safe.[us]rem(x,0) = {0, 1} safe.sdiv(min<T>, -1) =

On Fri, Feb 7, 2020 at 12:29 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > > It's not correct (output of Alive2): > > define half @fn(half %a) { > %b = fadd half %a, undef > ret half %b > } > => > define half @fn(half %a) { > ret half undef > } > Transformation doesn't verify! > ERROR: Value mismatch > > Example: > half %a

Hi, Consider the following test case: int foo(float *A, float *B, float *C, int len, int VSMALL) { for (int i = 0; i < len; i++) if (C[i] > VSMALL) A[i] = B[i] / C[i]; } In this test the div operation is conditional but llvm is generating unconditional div for this case: vector.body: ; preds = %vector.body, %vector.ph %index = phi i64 [

Hi LLVM, This is my idea I had some time ago, when I realized that LLVM did not support legalization of some arithmetic instructions like mul i256. I have implemented very simple and limited version of that in my project. Is it something LLVM users would appreciate? 1. The pass transforms IR and is meant to be run before CodeGen (after IR optimizations). 2. The pass replaces

Does LLVM support any target platforms on which the natural integer size/pointer size is smaller than 32 bits? For example, I noticed mention of PIC16, is that such a platform? If so, does the usual rule about the largest supported integer being the size of two pointers still apply? So that on that platform you can't use 64-bit integers, but you can use 32-bit integers?

Hello. My target architecture supports natively 16 bit integers (i16). Whenever I write in C programs using only short types, clang compiles the program to LLVM and converts the i16 data to i32 to perform arithmetic operations and then truncates the results to i16. Then, the InstructionCombining (INSTCOMBINE or IC) pass removes these conversions back and forth from i16, except for