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 match the // target. std::string Arch = ArchSplit.first; std::string Triple(Arch); Triple += '-'; Triple += ArchSplit.second; [...] Does content of Tripe = TargetTripleString? Of course with the difference of the container type. Do I miss something?
Hi Kamil,> Do I miss something?Very well spotted. I don't think you've missed anything, it's pointless. Looking through the git history the split served some purpose in the past, but we should probably just remove it now. Do you want to or shall I? Cheers. Tim.
Hmm. * The code segment indeed seems to do nothing. * Even then, std::string Arch not required at all. * iN86 logic lives in Triple::ArchType parseArch which is called by Triple::normalize anyhow. * The darwin logic means clang ignores whatever version LLVM_DEFAULT_TARGET_TRIPLE provides, replacing it with what uname says for this host. that on purpose? is this also done for other triples such as passed from command line? 2015-02-12 5:14 GMT+02:00 Kamil Rytarowski <n54 at gmx.com>:> 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 match the > // target. > std::string Arch = ArchSplit.first; > > std::string Triple(Arch); > Triple += '-'; > Triple += ArchSplit.second; > [...] > > Does content of Tripe = TargetTripleString? Of course > with the difference of the container type. > > Do I miss something? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150212/a6da3672/attachment.html>
Tim Northover wrote:> Hi Kamil, > > > Do I miss something? > > Very well spotted. I don't think you've missed anything, it's > pointless. Looking through the git history the split served some > purpose in the past, but we should probably just remove it now. > > Do you want to or shall I? >A cleanup patch was sent in a private mail. Please push it forward for trunk.> Cheers. > > Tim. >
Seemingly Similar Threads
- Runtime-configurable LLVM_DEFAULT_TARGET_TRIPLE by env var
- [LLVMdev] How to determine the architecture that clang/llvm will compile in CMake.
- [LLVMdev] Patch for the fact that all llvm python scripts are python 2.x compatible.
- Build status expectations for experimental targets
- [LLVMdev] CMake configuration: Detecting zlib.h header in windows.