search for: perfectshuffl

...- Original Message ----- > > From: "Alexey Samsonov" <samsonov at google.com> > > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Wednesday, April 30, 2014 3:30:12 PM > > Subject: [LLVMdev] Is it ok to nuke fpcmp and llvm-PerfectShuffle utils? > > > > > > > > They are not used in the regression test suite anymore, and are not > > even built in CMake build tree. > > You cannot nuke llvm-PerfectShuffle... that is the utility used to > generate the lib/Target/ARM64/ARM64PerfectShuffle.h, > l...

...t it should have build rules. If nothing else, can you file a bug report on this? It is building using configure + make. In good old days the perfect shuffle tables for PPC were generated through the normal build process like .td files. However, this was pretty useless - they do not change and thus perfectshuffle was excluded from the build process. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

They are not used in the regression test suite anymore, and are not even built in CMake build tree. -- Alexey Samsonov, Mountain View, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140430/c015da10/attachment.html>

...l" <hfinkel at anl.gov> > > Cc: "Alexey Samsonov" <samsonov at google.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > > Sent: Thursday, May 1, 2014 1:56:04 AM > > Subject: Re: [LLVMdev] Is it ok to nuke fpcmp and llvm-PerfectShuffle > utils? > > > > >> Ouch, indeed... Is it ok it has no build rules? > > > > > > I think that it should have build rules. If nothing else, can you > > > file a bug report on this? > > It is building using configure + make. In good old days the p...

...thout symbols) llvm[2]: ======= Finished Linking Release Executable tblgen (without symbols) llvm[2]: Compiling fpcmp.cpp for Release build llvm[2]: Linking Release executable fpcmp (without symbols) llvm[2]: ======= Finished Linking Release Executable fpcmp (without symbols) llvm[2]: Compiling PerfectShuffle.cpp for Release build llvm[2]: Linking Release executable llvm-PerfectShuffle (without symbols) llvm[2]: ======= Finished Linking Release Executable llvm- PerfectShuffle (without symbols) llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td make[1]: *** [/Users/rcleven/Desktop/llvm/build/lib...

...make -C $DD all make[2]: Entering directory `/home/csabaraduly/workspace/LLVM/build-clang/utils/TableGen' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/csabaraduly/workspace/LLVM/build-clang/utils/TableGen' \ SD=/home/csabaraduly/workspace/LLVM/llvm/utils/PerfectShuffle; \ DD=PerfectShuffle; \ if [ ! -f $SD/Makefile ]; then \ SD=PerfectShuffle; \ DD=PerfectShuffle; \ fi; \ if ([ ! -f $DD/Makefile ] || \ command test $DD/Makefile -ot \ $SD/Makefile ); then \ /home/csabaraduly/workspace/LLVM/llvm/autoconf/...

...needs that isn't installed with llvm. I checked, and all the headers for the src and obj are installed into ${prefix}/include/llvm and ${prefix}/include/llvm-c. All the main object files are the same as well. The only difference with binaries are that these aren't installed: fpcmp, llvm-PerfectShuffle, and tblgen. If this is the case, would it be possible to add something to llvm-gcc4's configure and Makefile to support building based solely off of a specified llvm-config? -e

...inja check-all", not "ninja all"[1]. check-all isn't a strict superset of all so while this covers most things, this does miss building a few things such as: > bin/clang-offload-wrapper > bin/llvm-itanium-demangle-fuzzer > bin/llvm-microsoft-demangle-fuzzer > bin/llvm-PerfectShuffle > ... > lib/libclang.so > ... > > For completeness, should this do "ninja all", "ninja check-all" as most buildbot builders do? > Does ninja all run the tests too? -Tom > Thanks > Russ > > [1] https://github.com/llvm/actions/blob/master/build...

...llvm[2]: Compiling count.c for Release+Asserts build llvm[2]: Compiling FileUpdate.cpp for Release+Asserts build llvm[2]: Compiling fpcmp.cpp for Release+Asserts build llvm[2]: Compiling FileCheck.cpp for Release+Asserts build llvm[2]: Compiling not.cpp for Release+Asserts build llvm[2]: Compiling PerfectShuffle.cpp for Release+Asserts build llvm[2]: Compiling ARMDecoderEmitter.cpp for Release+Asserts build llvm[2]: Linking Release+Asserts executable count (without symbols) llvm[2]: ======= Finished Linking Release+Asserts Executable count (without symbols) llvm[3]: Compiling gtest.cc for Release+Asserts...

....c for Release+Asserts build > llvm[2]: Compiling FileUpdate.cpp for Release+Asserts build > llvm[2]: Compiling fpcmp.cpp for Release+Asserts build > llvm[2]: Compiling FileCheck.cpp for Release+Asserts build > llvm[2]: Compiling not.cpp for Release+Asserts build > llvm[2]: Compiling PerfectShuffle.cpp for Release+Asserts build > llvm[2]: Compiling ARMDecoderEmitter.cpp for Release+Asserts build > llvm[2]: Linking Release+Asserts executable count (without symbols) > llvm[2]: ======= Finished Linking Release+Asserts Executable count (without symbols) > llvm[3]: Compiling gtest.cc...

...tract/ llvm-link/ llvm-nm/ llvm-prof/ llvm-readobj/ llvm-size/ llvm-stub/ macho-dump/ opt/ ../build/unittests: ADT/ Analysis/ Bitcode/ ExecutionEngine/ Makefile Support/ Transforms/ VMCore/ ../build/utils: count/ FileCheck/ FileUpdate/ fpcmp/ llvm-lit/ Makefile not/ PerfectShuffle/ TableGen/ unittest/ ==================configure artifacts====================

> I think my concern is that LLVM could prove to be too big and require too many resources for github's infrastructure. How many patches go into LLVM a day, and how many build and test jobs does GitHub allow users to run concurrently before being throttled? Please, no one confuse "what should be LLVM's official CIs" with "what can we do to make it easier for individuals

That source file was removed from LLVM in r232397 on March 16, 2015. It looks like lljvm hasn't been updated in a long time. LLVM's C++ APIs are not stable, so there is no expectation that a project built against LLVM's C++ API in 2015 would build or reasonably function against LLVM trunk. The project probably works against LLVM 3.6.2 which was (I believe) the last LLVM release to

...g directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/TableGen' make[1]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/utils' make[2]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/utils/FileCheck' make[2]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/utils/PerfectShuffle' make[2]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/utils/count' make[2]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/utils/TableGen' llvm[2]: Compiling PerfectShuffle.cpp for Release+Asserts build llvm[2]: Compiling FileCheck.cpp for Release+Asserts build llv...

...LVMFuzzerNoMain [ 49%] Built target LLVMFuzzer [ 49%] Built target LLVMPasses [ 49%] Built target LibOptionsTableGen [ 49%] Built target LLVMLibDriver [ 49%] Built target LLVMXRay [ 49%] Built target gtest [ 49%] Built target LLVMTestingSupport [ 49%] Built target FileCheck [ 49%] Built target llvm-PerfectShuffle [ 49%] Built target count [ 49%] Built target not [ 49%] Built target yaml-bench [ 49%] Built target LTO_exports [ 50%] Built target LTO [ 50%] Built target llvm-ar [ 50%] Built target llvm-ranlib [ 50%] Built target llvm-lib [ 50%] Built target llvm-config [ 50%] Built target llvm-lto [ 50%] Buil...

Thanks for providing the experimental data! It clearly shows the value of type sections in DWARF. Regarding why type sections are off by default, aside from the issue of consumers needing to understand them, there is a size penalty to type sections that becomes more evident in smaller projects (meaning, fewer compilation units). The size penalty can be balanced against the amount of

...get LLVMPasses >> [ 49%] Built target LibOptionsTableGen >> [ 49%] Built target LLVMLibDriver >> [ 49%] Built target LLVMXRay >> [ 49%] Built target gtest >> [ 49%] Built target LLVMTestingSupport >> [ 49%] Built target FileCheck >> [ 49%] Built target llvm-PerfectShuffle >> [ 49%] Built target count >> [ 49%] Built target not >> [ 49%] Built target yaml-bench >> [ 49%] Built target LTO_exports >> [ 50%] Built target LTO >> [ 50%] Built target llvm-ar >> [ 50%] Built target llvm-ranlib >> [ 50%] Built target llvm-lib...

...ptionsTableGen >>> [ 49%] Built target LLVMLibDriver >>> [ 49%] Built target LLVMXRay >>> [ 49%] Built target gtest >>> [ 49%] Built target LLVMTestingSupport >>> [ 49%] Built target FileCheck >>> [ 49%] Built target llvm-PerfectShuffle >>> [ 49%] Built target count >>> [ 49%] Built target not >>> [ 49%] Built target yaml-bench >>> [ 49%] Built target LTO_exports >>> [ 50%] Built target LTO >>> [ 50%] Built target llvm-ar >>> [ 50%] Built t...

hello, I am trying to build LLVM with default options. I am getting the following error message after make. [100%] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/metadata.c.o [100%] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/module.c.o [100%] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/object.c.o [100%] Building C object

...gt;>> [ 49%] Built target LLVMLibDriver >>>> [ 49%] Built target LLVMXRay >>>> [ 49%] Built target gtest >>>> [ 49%] Built target LLVMTestingSupport >>>> [ 49%] Built target FileCheck >>>> [ 49%] Built target llvm-PerfectShuffle >>>> [ 49%] Built target count >>>> [ 49%] Built target not >>>> [ 49%] Built target yaml-bench >>>> [ 49%] Built target LTO_exports >>>> [ 50%] Built target LTO >>>> [ 50%] Built target llvm-ar &gt...