similar to: Questions on LLVM vectorization diagnostics

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

> 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

Hi, Gerolf. We've been a bit quiet for some time. After listening to feedback on the project internally and externally, we decided to take a more generally accepted community development model ---- building up through a collection of small incremental changes ---- than trying to make a big step forward. That change of course took a bit of time, but we are getting close to the first NFC patch

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:

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

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, 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]

Hi, I am working with SCEVs, I see the unsigned division of SCEVs, it is not immediately clear to me why the signed division of SCEV expressions is not supported by SE? I would appreciate if some could clarify or point me to some links. -- Regards, DTharun -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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, 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

Hi Hideki, Thanks for the interesting writeup! > On Aug 27, 2016, at 7:15 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 25 August 2016 at 05:46, Saito, Hideki via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Now, I have one question. Suppose we'd like to split the vectorization decision as an Analysis pass and vectorization

> There is a fundamental problem with the way that ivdep is defined by Intel's current documentation, at least for C/C++. As you note in your Google doc, it essentially says that the optimizer may ignore loop-carried dependencies except for those dependencies it can definitely prove are present. These are not semantics that any other compiler can actually replicate, and is not equivalent to

Hello all, We are students from Indian Institute of Technology(IIT), Hyderabad, we would like to propose the addition of the following pragmas in LLVM that aide in (or possibly increase the scope of) vectorization in LLVM (in comparison with other compilers). 1. ivdep 2. Nontemporal 3. [no]vecremainder 4. [no]mask_readwrite 5. [un]aligned Could you please

On 8/8/19 2:03 PM, Hal Finkel wrote: Hi, First, as a high-level note, you posted a link to a Google doc, and at the end of the Google doc, you have a list of questions that you'd like answered. In the future, please put the questions directly in the email. For one thing, more people will read your email than will open your Google doc. Second, having the questions in the email should allow a

Hi, I would like to start a discussion about enabling the loop vectorizer by default for -Os. The loop vectorizer can accelerate many workloads and enabling it for -Os and -O2 has obvious performance benefits. At the same time the loop vectorizer can increase the code size because of two reasons. First, to vectorize some loops we have to keep the original loop around in order to handle the last

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

Hi, I need to run /bin/mount and /sbin/mount.cifs commands as nobody user (it has (bin/bash shell). So, I've edited /etc/sudoers and added: Cmnd_Alias CMD_MOUNT = /bin/mount Cmnd_Alias CMD_CIFS ) = /sbin/mount.cifs nobody ALL = NOPASSWD: CMD_MOUNT nobody ALL = NOPASSWD: CMD_CIFS But when I run the command as nobody (in the shell), I get the error: "mount

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