search for: loopinstsimplifi

Hi, I think we should remove the LoopInstSimplify pass, as it has no test coverage and no users (afaik). If you are using the pass, or think that it should stay in tree for some other reason, please let me know. Here's the patch: https://reviews.llvm.org/D44053 <https://reviews.llvm.org/D44053> vedant -------------- next part -------------- An HTML attachment was scrubbed... URL:

We're not actively using this, but from a design perspective I'm wondering if we should be using this or something like it.  At the moment, our various loop optimization assume mostly canonical input.  Some of the passes have been taught to deal with limited amounts of non-canonical-ism, but there's a strong code simplicity argument in favor of only handling canonical input and

The code is simple enough that I'd vote to delete and reintroduce later if needed.  :) Philip On 03/05/2018 01:23 PM, Vedant Kumar wrote: > Thanks for sharing this background information :). If you've got the > time, I think it'd be great to check this bulleted list into docs/. I > see that we don't have a Canonicalizations.rst or a > LoopOptimizations.rst --

Thanks for sharing this background information :). If you've got the time, I think it'd be great to check this bulleted list into docs/. I see that we don't have a Canonicalizations.rst or a LoopOptimizations.rst -- your notes look like a good starting point. Given that the pass seems to be doing the right thing from a design perspective, should it stay in tree? Since it's been

LLVM Weekly - #230, May 28th 2018 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/230>. Welcome to the two hundred and thirtieth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

LLVM Weekly - #220, Mar 19th 2018 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/220>. Welcome to the two hundred and twentieth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

llvm[4]: Compiling PoolAllocate.cpp for Release+Asserts build /home/NIKHILREDDY/WORK/LLVM_SRC/projects/poolalloc/lib/PoolAllocate/PoolAllocate.cpp: In member function ‘virtual bool llvm::PoolAllocate::runOnModule(llvm::Module&)’: /home/NIKHILREDDY/WORK/LLVM_SRC/projects/poolalloc/lib/PoolAllocate/PoolAllocate.cpp:403:16: error: ‘class llvm::Constant’ has no member named