similar to: [LLVMdev] How to determine the architecture that clang/llvm will compile in CMake.

Hi, I have having hard time to let cmake configuration detect the zlib header in windows with "Visual Studio 12" generator. My cmake configuration goes like >> Set path, include and lib environment variables to point to zlib headers and libraries. Cmake version is 2.8.12.2 cmake -G "Visual Studio 12" -D LLVM_TARGETS_TO_BUILD:STRING=%TARG% -D

On 5 Jun 2017, at 15:17, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 6/5/17 5:17 AM, Dmitry Golovin via llvm-dev wrote: >> I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. >> >> The configuration is the following: >> >> LIBCXX_HAS_MUSL_LIBC=ON >>

I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. The configuration is the following: LIBCXX_HAS_MUSL_LIBC=ON LIBCXX_HAS_GCC_S_LIB=OFF CLANG_DEFAULT_CXX_STDLIB=libc++ CLANG_DEFAULT_LINKER=lld CLANG_DEFAULT_RTLIB=compiler-rt LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl LLVM_TARGET_ARCH=x86_64

I want to build LLVM-based toolchain with Musl, I have LLVM sources with clang and lld (under `tools` directory) and libunwind, compiler-rt, libcxx and libcxxabi (under `projects` directory). All are the latest versions cloned from GitHub mirror, branch `master`. I'm trying to configure with the following options: CLANG_DEFAULT_CXX_STDLIB = libc++ CLANG_DEFAULT_RTLIB = compiler-rt

I'm trying to build LLVM on Windows 10 for x86_64. The cmake cmdline I used is c:\cmake-3.8.0-rc1-win64-x64\bin\cmake.exe -DLLVM_TARGETS_TO_BUILD=x86_64 -G "Visual Studio 14" . And this ultimately gives me: llvm-build: error: invalid target to enable: 'x86_64' (not in project) The source I'm trying to build is the llvm-3.8.0.src.tar.xz I got from

I have been working for extending test coverage for years. Nowadays, I have several cross-testing (target != host). See http://bb.pgr.jp/console Each of them (test-*-linux) is doing; - Assume a preceding builder passes with warming ccache. - All compilation units will hit ccache whenever the tree is built before lit. - Almost all compilation units will hit ccache except for Host.cpp when

Thanks! CIL [LeeHu] for a few comments… From: Xinliang David Li [mailto:xinliangli at gmail.com] Sent: Wednesday, May 27, 2015 9:29 AM To: Lee Hunt Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Capabilities of Clang's PGO (e.g. improving code density) On Tue, May 26, 2015 at 8:47 PM, Lee Hunt <leehu at exchange.microsoft.com<mailto:leehu at exchange.microsoft.com>> wrote:

Hello - I'm an Engineer in Microsoft Office after looking into possible advantages of using PGO for our Android Applications. We at Microsoft have deep experience with Visual C++'s Profile Guided Optimization<https://msdn.microsoft.com/en-us/library/e7k32f4k.aspx> and often see 10% or more reduction in the size of application code loaded after using PGO for key scenarios (e.g.

David, Yes, that is very helpful. Thanks! --randy From: Xinliang David Li [mailto:xinliangli at gmail.com] Sent: Wednesday, May 27, 2015 12:53 PM To: Randy Chapman Cc: Lee Hunt; llvmdev at cs.uiuc.edu Subject: Re: FW: [LLVMdev] Capabilities of Clang's PGO (e.g. improving code density) On Wed, May 27, 2015 at 12:40 PM, Randy Chapman <randyc at microsoft.com<mailto:randyc at

720beaedce6f19c81156fe20168f85989a8db53d CMakeLists.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index bb70f15..e327427 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -249,7 +249,7 @@ set(LLVM_DEFAULT_TARGET_TRIPLE "${LLVM_HOST_TRIPLE}" CACHE STRING set(TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}")

> On Feb 3, 2017, at 12:45 PM, Dylan McKay via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The builder isn’t marked as experimental so I think the expectation is that people keep it green and contact the bot owner if they need help figuring out why their change makes it red. That said, it sounds a bit odd to have a non-experimental builder for an experimental backend. >

Hi David! Thanks again for your help! I was wondering if you could clarify one thing for me? I find mention of “hot arc” optimization (-fprofile-arcs) , but I’m unclear if this is the same thing. Does Clang PGO do block reordering? It does reordering, but does not do splitting/partitioning. I take this to mean that PGO does block reordering within the function? I don’t see that the clang

Hello, I was looking at sys::getDefaultTargetTriple() (file: lib/Support/Unix/Host.inc ) and there is something unclear to me. std::string sys::getDefaultTargetTriple() { StringRef TargetTripleString(LLVM_DEFAULT_TARGET_TRIPLE); std::pair<StringRef, StringRef> ArchSplit = TargetTripleString.split('-'); // Normalize the arch, since the target triple may not actually

In InstCombineCompares.cpp, routine InstCombiner::FoldFCmp_IntToFP_Cst, there are these lines: // Comparisons with zero are a special case where we know we won't lose // information. bool IsCmpZero = RHS.isPosZero(); // If the conversion would lose info, don't hack on this. if ((int)InputSize > MantissaWidth && !IsCmpZero) return nullptr; Why check for positive

Yes, thanks David! For the intra-procedural Basic Block Reordering, do you have any data as to how much improvement that gives speed-wise for any perf tests you’ve measured? I’m thinking this may speed things up for things like application launch by a couple %. For perf intensive code (e.g. spreadsheet recalc), I would expect it would be more. From: Randy Chapman Sent: Wednesday, May 27, 2015

Hi Kurt, I have started to look into this, and I need some guidance about how to prioritize my repairs. There are basically 4 categories of warnings from gfortran?s pedantic critique of my packages: 1. Some errant tab characters it doesn?t like, 2. Too many or too few continue statements 3. Horrible (and obsolescent) arithmetic and computed gotos 4. undeclared doubles and dubious

Hi, I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select

Hi all, I am having some some trouble with LLVM 3.8... I built it with GCC 4.8.2 with cmake and no special CXX/C flags. That means in case of GCC that RTTI is switched on, I believe. However, building my MCJIT application against the just built LLVM and linking results in: libqdp.a(qdp_llvm.o):(.rodata._ZTIN4llvm8FCmpInstE[_ZTIN4llvm8FCmpInstE]+0x10): undefined reference to `typeinfo for

llvm-dev, In my ongoing saga to improve LLVM for embedded use, we would like to support stripping out unused intrinsics based on the LLVM targets actually being built. I’ve attached two patches. The first is a new flag for tablegen to take a list of targets. If passed tablegen will only emit intrinsics that either have empty target prefixes, or target prefixes matching one of the targets in the

On 6/21/2012 1:21 PM, Douglas Gregor wrote: > > On Jun 20, 2012, at 5:13 PM, Nick Lewycky <nlewycky at google.com > <mailto:nlewycky at google.com>> wrote: > >> Is there anybody who is certain that our autoconf dependency needs to >> stay around? Are there developers stuck on systems that don't have a >> recent enough cmake in their most recent