- User Since
- Aug 28 2017, 11:01 AM (111 w, 2 d)
This seems reasonable to me but I'm not an expert at LLVM's CMake setup.
Tue, Oct 15
Now using DAG.getAllOnesConstant()
Hi @craig.topper – Ping. Is this ready to land? Any other requests?
Sat, Oct 12
Is there an ETA for this fix? Without it, stage two testing fails:
Fri, Oct 11
I believe I've incorporated all of the feedback so far.
Thu, Oct 10
Incorporated PTEST feedback.
Tue, Oct 8
Sun, Oct 6
Sat, Oct 5
Is this patch ready to land then?
Simplified to just enabling AVX512BW for 512 and let 128/256 keep using AVX/AVX2.
Fri, Oct 4
That's a reasonable point. From my perspective:
Thu, Oct 3
Hi @mclow.lists – Ping. Any thoughts on the simplification you requested?
Tue, Oct 1
What platform was this tested on? This seems to be failing on my Fedora 31 x86_64 box:
Thu, Sep 26
The two tests:
I think trying to work out of the box with zero tuning in common scenarios and minimal tuning with uncommon scenarios is the right approach. If it were up to me, I’d flip the test: If windows then set the Windows define, otherwise pthreads.h exists, assume pthreads. If somebody is compiling “freestanding” like myself, then a link error about missing pthreads is expected behavior.
Hi @ldionne – That's a good question and I don't know the answer. If it's okay with you, I'd like to keep this change request narrowly focused on getting libcxx to work at all with freestanding environments.
Tue, Sep 24
Sun, Sep 22
This patch has now been run through update_llc_test_checks.
Hi @craig.topper – Thanks for writing the memset tests. I've expanded the non-zero one to also handle different preferred vector sizes.
Sat, Sep 21
The patch no longer depends on the AVX512 vector length extension.
Thanks for doing this work! I'm not an expert in this source code, so please wait for somebody else to approve it.
Neat! If you have the time, the BZHI bits-to-preserve operand only needs MOVB for initialization. That being said, MOVL probably avoids partial register update stalls, so maybe that’s why you’re seeing a performance gain.
Fri, Sep 20
Sep 16 2019
r371173 and r371521
Sep 13 2019
This breaks one of the clang unit tests on Fedora 30 (x86_64). Can we revert or fix this?
FAIL: Clang-Unit :: libclang/CrashTests/./libclangCrashTests/LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler (19745 of 51413) ******************** TEST 'Clang-Unit :: libclang/CrashTests/./libclangCrashTests/LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler' FAILED ******************** Note: Google Test filter = LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from LibclangParseTest [ RUN ] LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler LLVM ERROR: #pragma clang __debug llvm_fatal_error
Sep 12 2019
Sep 11 2019
Great. See: r371596
Sep 10 2019
Hi @uabelho – Try r371521
Sep 8 2019
The script doesn't have the ability to specify the name of the remote server. That being said, the script is only designed to work with one backend server due to how it hides SVN and in the future how it will hide GitHub status check magic.
- Working with and configuring upstream branches is fundamental to using git.
- It was a mistake for the git-llvm script to assume that the remote named "origin" is the official LLVM repository. For many people, "origin" is probably correct, but for many others, and the remote named origin depends on which repository was cloned first.
- Your local branch isn't setup correctly. You can fix that with git branch --set-upstream-to=origin/master (assuming that origin is the correct name of the remote server in your git repository).
- When you use git branch or git checkout, please remember to use --track if that is what you want/need.
Sep 6 2019
This code is trying too hard and failing. Either the result of gethostname() is canonical or it is not. If it is not, then trying to canonicalize it is – for various reasons – a lost cause. For example, a given machine might have multiple network interfaces with multiple addresses per interface, each with a different canonical name. Separably, the result of HostInfoPosix::GetHostname() and latency thereof shouldn't depend on whether networking is up or down or what network the machine happened to be attached to at any given moment (like a laptop that travels between work and home).
I think this might have caused a regression (my git-bisect is nearly complete):
FAIL: LLVM :: CodeGen/ARM/O3-pipeline.ll (24373 of 51236) ******************** TEST 'LLVM :: CodeGen/ARM/O3-pipeline.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /tmp/_update_lc/t/bin/llc -mtriple=arm -O3 -debug-pass=Structure < /home/dave/s/lp/llvm/test/CodeGen/ARM/O3-pipeline.ll -o /dev/null 2>&1 | grep -v "Verify generated machine code" | /tmp/_update_lc/t/bin/FileCheck /home/dave/s/lp/llvm/test/CodeGen/ARM/O3-pipeline.ll -- Exit Code: 1
Sep 4 2019
Aug 24 2019
Works for me. Thanks!
Aug 20 2019
Aug 6 2019
I don't think anybody is running doxygen over the Swift source right now, so I'll just escape the @ sign. That being said, can we improve this diagnostic? "command does not have an argument" is confusing when a given command does have an argument, just a malformed one. What do you think about "command must precede a word"? At least that gives a hint that the argument is not a "word" according to doxygen.
From the Swift language source (http://github.com/apple/swift):
Aug 5 2019
Just FYI – Having LLVM_ENABLE_PLUGINS_default depend on LLVM_ENABLE_PIC is a hack that should go away someday. Doing so requires that plugin dependencies either always build PIC (and therefore ignore LLVM_ENABLE_PIC), or are linked into the executables that load them and the plugin knows how to find them in the executable. In the case of the latter and on Mach-O platforms, this requires passing -bundle_loader $PATH_TO_EXECUTABLE to the linker when creating the plugin (a.k.a. "bundle"), but on ELF platforms, I'm not sure what needs to be done.
Hello – This change seems to have exposed a bug in -Wdocumentation argument parsing. For example, this warns when it shouldn't(?):
Jul 31 2019
Jul 15 2019
Jul 4 2019
I just did a quick test of this patch and now stage two testing works (Fedora 30, x86-64)