similar to: llvmbuildectomy

Hi Folks, An llvm-build chirurgal extraction was launched a few hours ago[1] and after an emergency action for the ocaml bindings [2], I'm glad to announce that the transplant looks in good shape! Although we did some intensive testing, given the size of the diff ```console $ git diff 9218ff50^..9218ff50 --shortstat 422 files changed, 1691 insertions(+), 7505 deletions(-) ``` side effects

Hi Folks, Now that LLVM 11.0.0 has been released, it's time to prepare for the final step envisionned in the previous RFC named *[RFC] Python 2 / Python 3 status* [0], ie. requiring Python3.6 for LLVM 12.0.0, to be released in 2021. At least Fedora already only ships Python3 and we didn't have much bugs reported wrt. Python compatibility for the LLVM toolchain. Indeed, all Python scripts

On Mon, Mar 02, 2015 at 12:12:34AM -0500, John Criswell wrote: > On 3/2/15 12:07 AM, Haopeng Liu wrote: > >Got it, thanks. But in my pass, I use function name to locate. Can I > >disable mangling in clang? > > No, but you can probably fine a library that can either mangle the original > name or demangle the name you're seeing in the LLVM bitcode. > > As an FYI,

Hi folks, Python2 has reached end of support[0], and many core Python packages are dropping pthon 2 support[1]. This is a subject that raises periodically on this mlist, with a rather strong no in 2018 [-1] and a slow move in 2019 [-2, -3]. Even if Python is not a core build requirement, it's used during some configurations steps (e.g. in the cmake export_executable_symbols function), for

> >> You can look at AddOptimizationPasses() in opt.cpp. > > > > As far as I understand, the two passmanager do not interleave their > > passes. It first runs all the function passes and below. Then all the > > module passes. So if you specify: > > > > opt -mymodulepass0 -myfunctionpass -mymodulepass1 > > > > What you actually get is:

At the beginning of the year, I've landed a large set of patches to support both Python 2 and Python3 in most Python scripts. Looks like I missed some of them :-) At that time, backward portability with Python2 was still relevant, and I suspect it will still be the case for a few distributions that ship Python2 by default. That being said, Even RHEL8 uses Python3 by default, so at some point

IMO, having non-critical utility scripts require python 3 should be allowed now. But, not yet for any scripts which are critical to build or test the distributed components. If we need to spend some time to fix the test runner to allow properly skipping tests of python3-only components when python3 isn't available, that seems entirely worthwhile, since we only need to do that once. On Tue,

Within the LLVM pass manager infrastructure, suppose we have two transformation passes, pass A makes some improvements, then pass B does likewise, but this creates opportunities for pass A to create further improvements (e.g. suppose B was function inlining) so it's desirable to run A again. How does the LLVM pass manager currently deal with this? -------------- next part -------------- An

I define "critical" as: anything which is required to build or test any components which are part of a release. The intent being that we DO continue to support python 2 for building llvm, and for end-users of llvm, for now. However, developers of LLVM can be assumed to be able to install python3 if they want to be able to run these various optional, auxiliary, scripts. Having a unit

It sounds like you ran into a bug in the test infrastructure's code to determine if python3 is supported. Fixing that might be harder, but it only needs to be fixed once no matter how much more python3 development there will be. Right now, most of our scripts were originally written for python 2, so certainly it's easy for them to support python 2. But, it was a lot of work by various

Hi, Following convention below: y(t) = Ax(t)+Bu(t)+eps(t) # observation eq x(t) = Cx(t-1)+Du(t)+eta(t) # state eq I modified the following routine (which I copied from: http://www.stat.pitt.edu/stoffer/tsa2/Rcode/Kall.R) to accommodate u(t), an exogenous input to the system. for (i in 2:N){ xp[[i]]=C%*%xf[[i-1]] Pp[[i]]=C%*%Pf[[i-1]]%*%t(C)+Q siginv=A[[i]]%*%Pp[[i]]%*%t(A[[i]])+R

Buenas noches estimados colegas: Adjunto la matriz,de la que quiero obtener, los promedios de cada elemento de los vectores que la componen. Me explico, el primer vector, tiene como primer elemento 23 y la suma de todos los elementos es 134; por lo tanto el promedio será 0.1716, el segundo elemento de dicho vector es 20, entonces el promedio sería 0.1492, del tercero el promedio es 0.1343 y así

$(llvm-config --libs | tr " " "\n" | grep gtest) returns: -lgtest_main -lgtest instead of non-valid: -lLLVMgtest_main -lLLVMgtest It also fixes: $(ld): cannot find -lLLVMgtest $(ld): cannot find -lLLVMgtest_main --- unittests/Makefile.unittest | 2 +- utils/llvm-build/llvmbuild/componentinfo.py | 4 ++-- utils/llvm-build/llvmbuild/main.py |

Hey all, Quick query on out of tree target support - at present I can drop a folder Foo into <llvm>/lib/Target/Foo and use the CMake option LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to pick up my target. The issue is that I still need to patch the one LLVMBuild.txt file in <llvm>/lib/Target with; |iff --git a/lib/Target/LLVMBuild.txt b/lib/Target/LLVMBuild.txt index 4112046..6e42cbe

Hi, I've been working on a set of patches to statically link polly in the LLVM tools. There remains an error I can't seem to solve when linking llvm-lto (all other tools luckily get linked correctly): it insists adding libLLVMipo.a after libLLVMPolly.a on the link command, resulting in an error of the form: PassManagerBuilder.cpp:(.text+0x499): undefined reference to

I believe we'd need LLVMBuild.txt even in autoconf build - for bunch of autogenerated stuff, e.g. list of all asmprinters / asmparsers / InitializeAllTargetInfos, etc., since targets are not autoregistered anymore. On Mon, Mar 9, 2015 at 7:20 PM, Eric Christopher <echristo at gmail.com> wrote: > Hi Neil, > > Weird, I'd think the cmake build should probably do something

On 1/21/2013 2:01 AM, Óscar Fuentes wrote: > Ashok Nalkund <ashoknn at qti.qualcomm.com> writes: > >> I was using the find_package(LLVM llvm/share/llvm/cmake) and >> llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native) to get >> the libraries to link against. This works well for the libLLVM* >> libraries, but how do I implement similar find stuff for

On 1/21/2013 10:25 AM, Ashok Nalkund wrote: > On 1/21/2013 2:01 AM, Óscar Fuentes wrote: >> Ashok Nalkund <ashoknn at qti.qualcomm.com> writes: >> >>> I was using the find_package(LLVM llvm/share/llvm/cmake) and >>> llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native) to get >>> the libraries to link against. This works well for the

Hello, Is there any package to install llvm 3.1 on solaris?  Standard installation by compiling the sources does not run smoothly. I found that similar issues have been addressed before, but without replies: http://clang-developers.42468.n3.nabble.com/Using-Clang-LLVM-on-sparc-solaris-td2807126.html I tried to install llvm 3.1 on a system with Sun Microsystems Inc.   SunOS 5.10      Generic

This is just standard behavior of the Python interpreter. The files are just a cache (it is not the sources being modified) and also won't be written if the source tree is made read only, and shouldn't cause a problem in practice. - Daniel On Jan 22, 2013, at 0:02, Duncan Sands <baldrick at free.fr> wrote: > I would have expected the .pyc files to go in the objects directory.