search for: libcallsemantics

...RelativePath="..\..\lib\Analysis > \LibCallAliasAnalysis.cpp" > + > > + </File> > + <File > + RelativePath="..\..\lib\Analysis > \LibCallSemantics.cpp" > + > > + </File> > + <File > RelativePath="..\..\lib\Analysis > \LoadValueNumbering.cpp" >> > </File> >...

attached is the diff of vcprojs that need to be changed to fix the VS build as of revision: 51224. I don't know if this catches all the missing bits, but this does build all the way through. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msvs.patch URL:

...x[i] = tmp_x * cos(angle) - y[i] * sin(angle); y[i] = y[i] * cos(angle) + tmp_x * sin(angle); } } In this case, the queries done by getModRefInfo are unable to avoid loading the ‘angle’ variable from memory for each call to sin/cos. Based on the comments in LibCallSemantics.h, it appears that LibCallAliasAnalysis should be able to handle this case by recognizing that sin/cos only affect errno. However, I don’t see any way of enabling this analysis without an appropriate derivation of LibCallInfo. Does anybody have info related to this? Thanks, Chris

Razvan Aciu wrote: > As I saw from the mailing list the MSVC 2005 patches were made to take into > account the new files from the development branch, files which are not in > the 2.3 release. So for now the below patch is the only one functional for > the release. If I am wrong, please someone correct me. > > If someone can make a 2005 patch for the release branch, it is ok.

A warning: R:\SDKs\llvm\trunk\include\llvm/Analysis/LibCallSemantics.h(63) : warning C4099: 'llvm::LibCallFunctionInfo' : type name first seen using 'class' now seen using 'struct' R:\SDKs\llvm\trunk\include\llvm/Analysis/LibCallAliasAnalysis.h(22) : see declaration of 'llvm::LibCallFunctionInfo' The problem line appears to b...

Our frontend can guarantee that loads from globals are rematerializable and do not alias with any stores in any function in the given module. We'd like the optimization passes (and ideally the register allocator as well) to be able to use this fact. The globals are not constant "forever" but are constant during the calling of any given function in the module. There seem to

...alIterator.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/IntervalPartition.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/LazyValueInfo.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/LibCallAliasAnalysis.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/LibCallSemantics.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/Lint.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/LiveValues.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/Loads.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/LoopDependenceAnalysis.h -- Installing: /...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel

...for Release+Asserts build llvm[2]: Compiling LazyValueInfo.cpp for Release+Asserts build llvm[3]: Compiling LowerInvoke.cpp for Release+Asserts build llvm[3]: Compiling LowerSwitch.cpp for Release+Asserts build llvm[2]: Compiling LibCallAliasAnalysis.cpp for Release+Asserts build llvm[2]: Compiling LibCallSemantics.cpp for Release+Asserts build llvm[3]: Compiling ResourcePriorityQueue.cpp for Release+Asserts build llvm[3]: Compiling Mem2Reg.cpp for Release+Asserts build llvm[2]: Compiling Lint.cpp for Release+Asserts build llvm[3]: Building X86.td disassembly tables with tblgen llvm[3]: Compiling MetaRenamer....