similar to: [LLVMdev] MSVC compile error with trunk

On Tue, May 12, 2009 at 11:55 PM, Chris Lattner <clattner at apple.com> wrote: > Dan, can you add IVUsers.cpp to the appropriate cmakefile? > > -chris > > > On May 12, 2009, at 10:54 PM, OvermindDL1 wrote: > >> On Tue, May 12, 2009 at 11:40 PM, Chris Lattner <clattner at apple.com> >> wrote: >>> >>> On May 12, 2009, at 10:24 PM,

Hi Tim, > From: Tim Creech <tcreech at umd.edu> > Subject: [LLVMdev] IVUsers (LoopPass) analysis in a ModulePass? > Date: September 1, 2011 11:46:28 AM PDT > To: llvmdev at cs.uiuc.edu > > Hi all, > I have a loadable ModulePass which does transformations, and I would like to > use IVUsers analysis within it. I noticed when I try to do this (via > the usual

On 09/14/2017 10:31 PM, Daniel Neilson wrote: > > >> On Sep 14, 2017, at 9:30 PM, Hal Finkel <hfinkel at anl.gov >> <mailto:hfinkel at anl.gov>> wrote: >> >> >> On 09/14/2017 10:43 AM, Daniel Neilson wrote: >>> Thank you for your thoughts, Hal. More information below... >>> >>>> On Sep 13, 2017, at 5:43 PM, Hal Finkel

On Sep 14, 2017, at 9:30 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: On 09/14/2017 10:43 AM, Daniel Neilson wrote: Thank you for your thoughts, Hal. More information below... On Sep 13, 2017, at 5:43 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: On 09/13/2017 01:01 PM, Daniel Neilson via llvm-dev wrote: … snip For

Hi all, I’ve most recently been grappling with a difficult to reproduce bug. I’ve traced the source of the difficulty in reproduction to the IVUsers analysis pass that is used by Loop Strength Reduction. Specifically, the IVUsers pass’s output is very sensitive to both the use list ordering of the instructions that it is looking at and the ordering of the Phi nodes in the header block of the loop

I have a warning when building with MSVC2k5, a benign warning, but I am trying to get rid of them. ..\..\..\..\trunk\lib\Transforms\Utils\AddrModeMatcher.cpp(208) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The line of code is: Scale = 1 << Scale; Where Scale is an int64_t, however, 1 is an int32_t (since

I have a warning when building with MSVC2k5, a benign warning, but I am trying to get rid of them. ..\..\..\..\trunk\lib\Transforms\Utils\AddrModeMatcher.cpp(208) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The line of code is: Scale = 1 << Scale; Where Scale is an int64_t, however, 1 is an int32_t (since

Thank you for your thoughts, Hal. More information below... On Sep 13, 2017, at 5:43 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: On 09/13/2017 01:01 PM, Daniel Neilson via llvm-dev wrote: … snip For example, the following IR will produce different sets of IV users if either: i) The order of the PHI nodes in the %loop block are reordered; or ii) The

In the llvm file include/llvm/Support/DataTypes.h (.in/.cmake), for MSVCit defines some macros that are defined in the cstdint.hpp file in boost (and boost does it better, detailed below): The basic error is: R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(347) : warning C4005: 'INT8_C' : macro redefinition

hi, On Sat, Mar 17, 2012 at 2:11 AM, Andrew Trick <atrick at apple.com> wrote: > Yep. I normally do that. I was under some strange impression last night that SmallPtrSetImpl wasn't a template. The patch is incorrect because the SmallPtrSetImpl is neither a template nor has an "insert" function... After a detailed look at the header of SmallPtrSet, I found that the

Hi all, I have a loadable ModulePass which does transformations, and I would like to use IVUsers analysis within it. I noticed when I try to do this (via the usual addRequired<IVUsers>() and getAnalysis<IVUsers>(*F)), opt fails an assert: opt: /home/tcreech/build/llvm-2.9/include/llvm/PassAnalysisSupport.h:239: AnalysisType& llvm::Pass::getAnalysisID(const void*,

As came up recently in other threads, loop passes really get in the way. Here are some of the ways: - There is only one Loop analysis pass - IVUsers. It seems unlikely that the loop nest walk is critical to computing this or preserving it. - Almost all of the things we think of as "required" and dependencies are actually *transforms* that canonicalize the form of a loop into particular

Hi LLVMers, I can't figure out why these errors exits: ------------------------- llvm[2]: Linking Debug executable opt c:/projects/build/MinGW/llvm-4-1/Debug/lib/LLVMProfilePaths.o(.text$_ZN4llvm10BranchInstC1EPNS_10BasicBlockES2_+0x52): In function `ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPN4llvm8FunctionEPNS3_5GraphEEEE10deallocateEPSA_j':

I constructed an LLVM 2.7 VS solution with cmake, but it has 66 projects: ALL_BUILD, ".\ALL_BUILD.vcproj" BrainF, "examples\BrainF\BrainF.vcproj" Fibonacci, "examples\Fibonacci\Fibonacci.vcproj" FileCheck, "utils\FileCheck\FileCheck.vcproj" HowToUseJIT,

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, "Jingyue Wu" <jingyue at google.com> > Sent: Wednesday, July 1, 2015 2:27:59 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > >

On 12/14/2011 01:25 AM, Hal Finkel wrote: > Tobias, > > I've attached an updated copy of the patch. I believe that I accounted > for all of your suggestions except for: > > 1. You said that I could make AA a member of the class and initialize it > for each basic block. I suppose that I'd need to make it a pointer, but > more generally, what is the thread-safely

> > I just moved to the CMake solution. By the way, the generated libs > > haven't the same names. > > Which ones? The only difference is that we now generate .lib files > where > .obj were generated on the past, and require a parameter to be passed > to > the linker for including them on the final executable. I was linking with VMCore.lib support.lib

I am considering using LLVM in a project for a Windows CE where space is at a premium. My jaw dropped when I checked the size of HowToUseJIT.exe (VC++ Win32 debug): 15.4 MB! The release build of HowToUseJIT is "only" 3.39 MB, but this is still 85% larger than the binary to which I was thinking of adding LLVM. The top ten LLVM libraries (Win32 *.lib) are pretty huge: Release Bld Debug

One thing that helps me understand complex software is a dependency graph. I found an LLVM dependency graph at https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_16/docs/UsingLibraries.html#dependencies but it's really messy and hard to follow. From that graph I made a cleaner graph by hand (attached)... sorry about the fax-quality scan. But I have some questions about it... -

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Jingyue Wu" <jingyue at google.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, June 30, 2015 8:16:13 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > > Hi Adam, > > Jingyue is right. We need to keep