similar to: Higher level program analysis

Devirtualization is an example of predicting calls and is much more easily done on a higher-level representation. It is simply easier to reason about certain things given information that is lost during translation to LLVM IR. The MLIR project makes similar arguments. It would be helpful to know what's being attempted here. I'm not sure what the (hardware?) branch predictor has to do

Hi, David: Good point, it will be interesting to see speculative compilation in this context applying on devirtualization, with high level (type) information if applicable. > On Mar 28, 2019, at 2:35 PM, preejackie <praveenvelliengiri at gmail.com> wrote: > > Hi David & Bekket, > > Thanks your replies :) > > David, Indent here is: ORC v2 JIT APIs has

Hi Bekket, Sorry for the delayed reply. By appropriate, I mean performance of compiled native code. I was referring other JIT implementations like LuaJIT & webkit FTL JIT to see how they implement their JIT. I have gone through the design of Spider Monkey & Android runtime (ART) JIT. As, you said both region based and method based compilation unit have their own advantage &

preejackie via llvm-dev <llvm-dev at lists.llvm.org> writes: > Are you suggesting that static analysis is much inferior than > profiling in finding "next executing function" ? I'm stuck at > deciding which one to prefer & implement during this summer project, > Could you please help me? I suspect this is highly code-dependent. For example, it's probably

Hi all, I would like to propose "Speculative compilation support in ORC v2 JIT API" for this year GSoC summer project. Project Description: Speculative compilation support. One of the selling points of the concurrent ORC APIs is that you can start compiling a function before you need it, in the hope that by the time that you do need it it is already compiled. However, if we just

To my knowledge that intrinsic IS generated by frontends like Clang when using _builtin_return_address(), i could be wrong though Zhang > 在 2018年9月5日，10:47，Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org> 写道： > > and

Hi Bekket, Thank you for your reply. Earlier I came across a paper called "Dynamic Look Ahead Compilation: Hide JIT compilation latencies", it devised some methods for JIT compilation of functions before the actual call takes place by using call graph analysis, branch probabilities to generate a list of functions with high likelihood of execution in near future. In my opinion it

Hi Bekket, I don't see any use case in the codebase adding clEnumValEnd at the end of list (for example, [1]), I also don't see there is clEnumValEnd. Do I miss something here? [1] http://llvm.org/doxygen/DwarfDebug_8cpp_source.html Regards, chenwj 2017-06-06 9:53 GMT+08:00 Bekket McClane via llvm-dev < llvm-dev at lists.llvm.org>: > Hi, > > Can anyone help reviewing

Hi, The argument list for cl::values in command line library should be end with null or clEnumValEnd. But the tutorial page(http://llvm.org/docs/CommandLine.html <http://llvm.org/docs/CommandLine.html>) doesn’t follow the rule, which would cause program crash during runtime. I’d send a code review: https://reviews.llvm.org/D33861 <https://reviews.llvm.org/D33861> Please cc other

> Mehdi Amini <mehdi.amini at apple.com> 於 2016年10月19日 上午11:30 寫道： > > >> On Oct 18, 2016, at 6:28 PM, Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> The LLVM variant we're building now contains usage of a third-party threading library, and we would like to push our work

Thanks for swift reply > Ahmed Bougacha <ahmed.bougacha at gmail.com> 於 2016年6月28日 下午8:11 寫道： > > On Tue, Jun 28, 2016 at 4:42 AM, Bekket McClane via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> Hi, >> I'm new to LLVM and I'm doing research on factors of compilation time, >> especially instruction

> Mehdi Amini <mehdi.amini at apple.com> 於 2016年11月30日 上午5:14 寫道： > >> >> On Nov 29, 2016, at 4:02 AM, Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> Though there exists lots of researches on parallelizing or scheduling optimization passes, If you open up the time matrices of

Hi LLVM folks, As the sequel of my blog posts shared previously: Writing LLVM Pass in 2018 - [Part I](https://medium.com/@mshockwave/writing-llvm-pass-in-2018-part-i-531c700e85eb <https://medium.com/@mshockwave/writing-llvm-pass-in-2018-part-i-531c700e85eb> ) and [Part II](https://medium.com/@mshockwave/writing-llvm-pass-in-2018-part-ii-640f680978ec

Hi David, Thanks for your reply. I find that I need to add some new types of profile data that are specific to JIT environment like Function Ordering. Function Ordering is similar to dynamic call graph which records the execution of functions at runtime along with the order in which they are called. Eg: Suppose they are 5 functions (F1..F5). F1 calls other functions in the order described

I'm still relatively new to llvm, good to know these errors are from CodeGen. On 03/03/19 10:49 AM, Tim Northover wrote: > On Sat, 2 Mar 2019 at 21:00, preejackie via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Could you please explain how you are using this? like commands >> >> When I run this IR in opt, it doesn't throw any errors. > The error

Hi David! Thanks for reaching out, the codegen part of the tutorial is fine, but when I try to generate the object code file, it throws segfault. Also please note that I'm using release build of llvm, actually I don't know whether that is the root cause or not. I also run through valgrind, it seems like a invalid read from stack. |||Error Summary: | |1 errors in context 1 of 1:

On Tue, Jun 28, 2016 at 5:49 AM, Bekket McClane <bekket.mcclane at gmail.com> wrote: > Thanks for swift reply > > Ahmed Bougacha <ahmed.bougacha at gmail.com> 於 2016年6月28日 下午8:11 寫道： > > On Tue, Jun 28, 2016 at 4:42 AM, Bekket McClane via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi, > I'm new to LLVM and I'm doing research on factors

Hello With LLVM 4.0 my code is being compiled correctly. but with LLVM 7.0.1 I am getting following error; *llvm-7.0.1.src/include/llvm/IR/Module.h:356:43: error: no matching constructor for initialization of 'SmallVector<llvm::Type *, sizeof...(ArgsTy)>' SmallVector<Type*, sizeof...(ArgsTy)> ArgTys{Args...};* What is the reason? Please help. Thank You

I’m going to travel with another person, so 2 people in total Cheers, Hsu > Tobias Grosser <tobias.grosser at inf.ethz.ch> 於 2017年3月26日 下午4:16 寫道： > > We have a table reserved at Tante Maja, 18:00 for 15 people. I am travel > with 5 other people, so 10 more spots are open. Please let me know > within 30 minutes if you want a spot, such that I can confirm the >

Hi, I've been studying the global instruction selector introduced recently. One of the properties of global instruction selectors is that they select instructions across basic blocks such that they can get more information in order to choose optimal patterns. However, the current global isel implementation still iterates over BBs within functions, which is same as the original SelectionDAG