similar to: Extending StoreInst/LoadInst

Hi Johannes et al, > -----Original Message----- > From: Doerfert, Johannes <jdoerfert at anl.gov> [..] > On 11/06, Jeroen Dobbelaere wrote: > > >From: Alexey Zhikhartsev > > [..] > > > We would love to see your patches merged as soon as possible, so I was > wondering: do you think the lack of bitcode support will prevent that from > happening? >

Mike, Holger, thanks for the tips, but being a long-time subversion user, I already knew this all :-) The problem was that I did an SVN merge from branch to trunk, and I ended up with: ... M include/llvm/User.h A + include/llvm/OperandTraits.h M include/llvm/Instruction.h ... The little "+" after the "A" means, the file got copied unchanged, and I think this is

Hi, everyone, We've had a number of discussions recently, including on the Flang technical call, about potential improvements to LLVM's alias analysis to support handling restrict and restrict-like semantics. We would like to try having a call to discuss these issues further. Please, if you're interested in joining, indicate your availability (prior to the end of this week):

Chris Lattner wrote: > Hi Gabor, I don't see OperandTraits.h. Sorry, I relied "svn diff" to include freshly added files. Apparently it did not :-/ Here are they. I pondered of putting all in Use.cpp into Value.cpp, but I am not so sure. Cheers, Gabor -------------- next part -------------- A non-text attachment was scrubbed... Name: OperandTraits.h Type:

To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC please use this information: Meeting URL https://bluejeans.com/643493129?src=join_info Meeting ID 643 493 129 Want to dial in from a phone? Dial one of the following numbers: +1.312.216.0325 (US (Chicago)) +1.408.740.7256 (US (San Jose)) +1.866.226.4650 (US Toll Free) (see all numbers -

Hi Alexey, Adding llvm-ir bitcode support means adding/adapting the tags for LOAD/STORE instructions and adding the support for the noalias_sidechannel at the right places. I had a short attempt to implement it when preparing the public patches, but I am not familiar with that part of the llvm code. When I noticed that it would take a lot longer than anticipated, I postponed it. Also because it

Hi Gabor, Thanks for posting the memory savings. 13% less memory usage in 447.dealII is very impressive. I haven't taken more than a very brief peek at this patch, but I have a few questions already. Is there a header missing? I don't see DECLARE_TRANSPARENT_OPERAND_ACCESSORS defined anywhere. Also, what affect does this macro have on doxygen? In User.h: +public: + template

Great, thanks! Are you planning on just talking about these things with slides? Do we have other things to which we can link for people to read? -Hal Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ________________________________ From: Tarique Islam <tislam at ca.ibm.com> Sent: Thursday, May 21, 2020 8:19:31 AM To:

Hi Alexey, >From: Alexey Zhikhartsev [..] > We would love to see your patches merged as soon as possible, so I was wondering: do you think the lack of bitcode support will prevent that from happening? Yes, I think that the lack of bitcode support will prevent it. During the Developers meeting, I also talked with Hal and Johannes. They had some extra remarks: - (1) the restrict

I'm make silly error (swap arguments in llvm::StroreInst constructor call: llvm::Value* var = genExpr(bb,*varExpr,false); llvm::Value* val = genExpr(bb,*valExpr,true ); llvm::StoreInst* lStore = new llvm::StoreInst(var,val,bb); instead assert(var && var->getType()->getTypeID()==llvm::Type::PointerTyID && "var side isn't pointer type"); llvm::StoreInst*

Hi, everyone, We had a great call last month, and progress is definitely being made on several fronts. The notes from our last call are available here: https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit#heading=h.vpxs8lkuxy79 and, also, pasted below. DOODLE POLL: As we discussed on our last call, I would like to schedule a regular call to discuss

On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote: > Hi all, > > I have reported more than enough about the space savings achieved > and the associated costs, here comes the current patch for review. > > Since this one is substantially smaller than the previous one, I did > not cut it in pieces. The front part is about headers and the rest > the .cpp and other files. Hi

Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

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

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

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

> 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

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