similar to: Question about Instruction Selection

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

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

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 of compilation time, > especially instruction selection and scheduling. One of the academic papers > I read, > https://llvm.org/svn/llvm-project/www-pubs/trunk/2008-CGO-DagISel.pdf (Koes, > David Ryan, and Seth

> 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, Though there exists lots of researches on parallelizing or scheduling optimization passes, If you open up the time matrices of codegen(llc -time-passes), you'll find that the most time consuming task is actually instruction selection(40~50% of time) instead of optimization passes(10~0%). That's why we're trying to parallelize the (target-independent) instruction selection process

> On Nov 29, 2016, at 1:14 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> 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

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

On Tue, Jan 31, 2017 at 7:12 AM, Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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. >

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 LLVM variant we're building now contains usage of a third-party threading library, and we would like to push our work upstream in the future. Are third-party libraries welcomed to be added in LLVM? If yes, what folder structure should we arrange? B.R. -- Bekket McClane Department of Computer Science, National Tsing Hua University -------------- next part -------------- An HTML

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

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

Is the algorithm described in the article "Near-Optimal Instruction Selection on DAGs (https://llvm.org/pubs/2008-CGO-DagISel.html)" really used in llvm instruction selection? I've studied implementation (SelectionDAGISel.cpp) and I see that instructions are selected by target specific MatcherTable generated by llvm-tblgen. In the implementation the first matching pattern from

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 >

On Sun, Mar 26, 2017, at 04:23 PM, Piotr Padlewski via llvm-dev wrote: > Hey Tobias, > 4 spots for me and my folks. Thanks for taking care Tobias! OK. We are down at 2 spots (maybe a little bit more) Piotr 4 spots Tobias 5 spots Bekket 2 spots Alex 2 spots 13 out of 15 spots taken. Let me know if you wanna join. I can try to get some more spots. Best, Tobias Best, Tobias

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

On 08/16/2018 07:52 PM, Bekket McClane via llvm-dev wrote: > > >> On Aug 16, 2018, at 4:41 PM, Troy Johnson via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Concerning slide 16 >> of https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf >>   >> Specifically “Currently, LLVM

Hi all, I have seen in multiple cases that, usually at the beginning of the function. if a BranchInst is encountered the next block might have %0 indicated as predecessor. I think it is a way to say "no predecessors found". Am I correct? Few examples just for clarifying what I mean: define noalias %struct.png_struct_def* @png_create_read_struct_2(i8* %user_png_ver, i8* %error_ptr, void