User Details
- User Since
- Aug 28 2017, 11:01 AM (252 w, 3 d)
Mar 25 2022
Okay. I'll try to remember to create a followup bug after this lands. I'm sure I'm naive about it, but it seems to me that after register allocation, MOV $0, <reg> instructions should move earlier (when possible) in the basic block to get out of the way of EFLAG dependencies and allow the MOV $0, <reg> to XOR <reg>, <reg> optimization, but that's just me hand waving.
I was just surprised to see that the last four lines didn't swap the BT and the zeroing of EDX. Maybe this is a separate problem. This seems like the natural output of the last four lines of the example above:
This is a great improvement but a scenario is still missing. For example, from a build of LLVM with this change applied (i.e. self hosted):
Oct 5 2021
If you want to test more, please let me know and I can test them on my Fedora box.
"the buildbot"? There are many. I'd be surprised if this weren't failing on at least one of them. It doesn't seem like subtle terminfo behavior is essential to this test. Can we please trim down the adjustments to only changing the speed? For example:
diff --git i/lldb/unittests/Host/posix/TerminalTest.cpp w/lldb/unittests/Host/posix/TerminalTest.cpp index ecdb5480216439903b9fc12c39b3d47cb62f9134..e865d44bf6cb9085f07c11e06be34f33a7bd32b9 100644 --- i/lldb/unittests/Host/posix/TerminalTest.cpp +++ w/lldb/unittests/Host/posix/TerminalTest.cpp @@ -80,14 +80,8 @@ TEST_F(TerminalTest, SaveRestoreRAII) { terminfo = orig_terminfo;
The FD in question is 3. Here is the output from lsof: HostTests 80108 dave 3u CHR 5,2 0t0 231 /dev/ptmx
This is failing on my Fedora 34 (x86-64) box. Is this expected?
FAIL: lldb-unit :: Host/./HostTests/TerminalTest.SaveRestoreRAII (78548 of 79402) ******************** TEST 'lldb-unit :: Host/./HostTests/TerminalTest.SaveRestoreRAII' FAILED ******************** Script: -- /tmp/_update_lc/r/tools/lldb/unittests/Host/./HostTests --gtest_filter=TerminalTest.SaveRestoreRAII -- Note: Google Test filter = TerminalTest.SaveRestoreRAII [==========] Running 1 test from 1 test suite. [----------] Global test environment set-up. [----------] 1 test from TerminalTest [ RUN ] TerminalTest.SaveRestoreRAII /home/dave/ro_s/lp/lldb/unittests/Host/posix/TerminalTest.cpp:93: Failure Expected equality of these values: tcsetattr(m_pty.GetPrimaryFileDescriptor(), 0, &terminfo) Which is: -1 0 [ FAILED ] TerminalTest.SaveRestoreRAII (4 ms) [----------] 1 test from TerminalTest (4 ms total)
Sep 18 2021
Also, when this lands again, please ensure that all the tests don't accidentally dump build artifacts into the source directory. Specifically, the following test was missing -o -: clang/test/OpenMP/metadirective_messages.cpp
Jul 1 2021
LGTM too. And I agree that substring matching would be undesirable.
Jun 30 2021
The -stats command line flag requires asserts, so either the test needs REQUIRES: asserts or the stats testing needs to be broken into a separate test.
Jun 7 2021
I filed a bug about the IR not being canonicalized. Let's wait for that before proceeding on generating VPMOVQ2M:
Actually, wait. Something weird is going on at the mid-level. These two functions should generate the same optimized IR, right?
I'm surprised that this didn't break existing tests. Where is the right place to update the test suite?
May 28 2021
May 27 2021
LGTM but I don't feel ownership over this code.
Sorry for the noise. I reran the bisect. The test in question is still failing, but it turns out to be failing unreliably so git-blame is fairly useless without a reliable test.
I have an auto-bisecting multi-stage cron job that has identified this change as the source of a regression. Does the following seem plausible?
May 25 2021
I've verified that this patch no longer causes my multi-stage cron job to regress. Thanks!
Actually, it is more complicated, and you're right that it also can involve overflow. I'm not sure if this is a trivial optimization when dependent comparisons are involved.
I can check it, but I'm a bit concerned about the comment and what it implies. The problem is NOT overflow, but that comparison operations need to be redistributed during this optimization (or dependent comparisons need to disable the optimization). So in pseudocode, the original code that miscompiled looks like this:
May 19 2021
Thanks! Also, I feel fairly confident about this. My auto-bisecting cron job is really paranoid. For example, it always does a multi-stage test to verify that the commit *before* the commit blamed by git-bisect actually works. That's what I was waiting for. Also, I then verified by trying to move one commit ahead in the history to this commit to get an A/B test and I then confirmed that this is the regression. Thanks again for reverting this.
Verified. Second stage miscompile. If it matters (and it sometimes does), my first stage is built without asserts.
Lots of crashes like this:
FAIL: Clang-Unit :: Format/./FormatTests/FormatTest.FormatsCompactNamespaces (23265 of 76779) ******************** TEST 'Clang-Unit :: Format/./FormatTests/FormatTest.FormatsCompactNamespaces' FAILED ******************** Note: Google Test filter = FormatTest.FormatsCompactNamespaces [==========] Running 1 test from 1 test suite. [----------] Global test environment set-up. [----------] 1 test from FormatTest [ RUN ] FormatTest.FormatsCompactNamespaces FormatTests: /home/dave/ro_s/lp/clang/lib/Basic/SourceManager.cpp:865: clang::FileID clang::SourceManager::getFileIDLoaded(unsigned int) const: Assertion `0 && "Invalid SLocOffset or bad function choice"' failed. #0 0x0000000000604313 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x604313) #1 0x0000000000602962 llvm::sys::RunSignalHandlers() (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x602962) #2 0x0000000000604d8a SignalHandler(int) Signals.cpp:0:0 #3 0x00007ffff7fa4a20 (/lib64/libpthread.so.0+0x13a20) #4 0x00007ffff7b392a2 raise (/lib64/libc.so.6+0x3d2a2) #5 0x00007ffff7b228a4 abort (/lib64/libc.so.6+0x268a4) #6 0x00007ffff7b22789 (/lib64/libc.so.6+0x26789) #7 0x00007ffff7b31a16 (/lib64/libc.so.6+0x35a16) #8 0x000000000064922c clang::SourceManager::getFileIDLoaded(unsigned int) const (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x64922c) #9 0x00000000003e734c clang::SourceManager::getDecomposedLoc(clang::SourceLocation) const CleanupTest.cpp:0:0 #10 0x000000000064b231 clang::SourceManager::isBeforeInTranslationUnit(clang::SourceLocation, clang::SourceLocation) const (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x64b231) #11 0x000000000066c05e clang::format::AffectedRangeManager::computeAffectedLines(llvm::SmallVectorImpl<clang::format::AnnotatedLine*>&) (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x66c05e) #12 0x00000000006ae393 clang::format::UsingDeclarationsSorter::analyze(clang::format::TokenAnnotator&, llvm::SmallVectorImpl<clang::format::AnnotatedLine*>&, clang::format::FormatTokenLexer&) (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x6ae393) #13 0x0000000000690d1a clang::format::TokenAnalyzer::process() (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x690d1a) #14 0x0000000000665643 std::__1::__function::__func<clang::format::internal::reformat(clang::format::FormatStyle const&, llvm::StringRef, llvm::ArrayRef<clang::tooling::Range>, unsigned int, unsigned int, unsigned int, llvm::StringRef, clang::format::FormattingAttemptStatus*)::$_4, std::__1::allocator<clang::format::internal::reformat(clang::format::FormatStyle const&, llvm::StringRef, llvm::ArrayRef<clang::tooling::Range>, unsigned int, unsigned int, unsigned int, llvm::StringRef, clang::format::FormattingAttemptStatus*)::$_4>, std::__1::pair<clang::tooling::Replacements, unsigned int> (clang::format::Environment const&)>::operator()(clang::format::Environment const&) Format.cpp:0:0 #15 0x0000000000655d6e clang::format::internal::reformat(clang::format::FormatStyle const&, llvm::StringRef, llvm::ArrayRef<clang::tooling::Range>, unsigned int, unsigned int, unsigned int, llvm::StringRef, clang::format::FormattingAttemptStatus*) (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x655d6e) #16 0x000000000065640f clang::format::reformat(clang::format::FormatStyle const&, llvm::StringRef, llvm::ArrayRef<clang::tooling::Range>, llvm::StringRef, clang::format::FormattingAttemptStatus*) (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x65640f) #17 0x00000000003ef27f clang::format::(anonymous namespace)::FormatTest::format(llvm::StringRef, clang::format::FormatStyle const&, clang::format::(anonymous namespace)::FormatTest::StatusCheck) FormatTest.cpp:0:0 #18 0x0000000000407eed clang::format::(anonymous namespace)::FormatTest_FormatsCompactNamespaces_Test::TestBody() FormatTest.cpp:0:0 #19 0x000000000060cc53 testing::Test::Run() (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x60cc53) #20 0x000000000060dc16 testing::TestInfo::Run() (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x60dc16) #21 0x000000000060e470 testing::TestSuite::Run() (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x60e470) #22 0x000000000061bb23 testing::internal::UnitTestImpl::RunAllTests() (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x61bb23) #23 0x000000000061b59d testing::UnitTest::Run() (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x61b59d) #24 0x000000000060555b main (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x60555b) #25 0x00007ffff7b23b75 __libc_start_main (/lib64/libc.so.6+0x27b75) #26 0x00000000003ddd8e _start (/tmp/_update_lc/t/tools/clang/unittests/Format/./FormatTests+0x3ddd8e)
Just a heads up, my auto-bisecting multi-stage cron job has identified this change as the source of a second stage regression in a bunch of clang unit tests. I'm about to verify by hand, but it'll take a while.
May 17 2021
LGTM but I don't feel authoritative for the lit code.
May 6 2021
Yes, Fedora 34 (x86-64).
May 4 2021
Apr 29 2021
Apr 27 2021
Apr 23 2021
I have an auto bisecting cron job that has twice identified this change as the source of a regression when building release (no asserts). Is the following expected or can we get a quick fix?
It's still failing but I can disable HSA on this machine for now. FYI --
FAILED: tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o /p/tllvm/bin/clang++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/tools/amdgpu-arch -I/home/dave/ro_s/lp/clang/tools/amdgpu-arch -I/home/dave/ro_s/lp/clang/include -Itools/clang/include -Iinclude -I/home/dave/ro_s/lp/llvm/include -Werror=switch -Wno-deprecated-copy -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types -O2 -DNDEBUG -march=skylake -fno-vectorize -fno-slp-vectorize -fno-tree-slp-vectorize -fno-exceptions -fno-rtti -std=c++14 -MD -MT tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o -MF tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o.d -o tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o -c /home/dave/ro_s/lp/clang/tools/amdgpu-arch/AMDGPUArch.cpp /home/dave/ro_s/lp/clang/tools/amdgpu-arch/AMDGPUArch.cpp:14:10: fatal error: 'hsa.h' file not found #include <hsa.h> ^~~~~~~ 1 error generated.
Apr 22 2021
I removed all HSA/ROCM via the package manager and everything is fine now. Have you considered using __has_include() instead of CMake? It seems to be supported by all contemporary compilers, even MSVC.
And if it helps:
This change broke multi-stage builds (even if AMDGPU is disabled as a target). The problem is that clang/tools/amdgpu-arch/AMDGPUArch.cpp can't find hsa.h. Is there a quick fix?
I'm the third person to notice the same problems, but this time on Fedora 34 (x86-64) so I reverted the change.
My mistake. The bisect tripped over a unreliable test. The real problem was 04733181b5136e2b3df2b37c6bdd9e25f8afecd0 and people are already piling onto that as being broken.
My automatically bisecting cron job identified this commit as the source of a regression on Fedora 34 (x86-64). It seems like a few dozen libc++ tests are now failing with errors like this:
Apr 15 2021
Apr 12 2021
Sorry, I got distracted. If it were up to me, I'd prefer tuning numbers that are, without checking, unambiguously better than the current code gen. In particular the code gen for KNL is awful. Furthermore, I think that fine tuning this further has diminishing returns for various reasons. Are people okay with that?
Apr 6 2021
I have an auto-bisecting cron job that has identified this change as a second-stage regression on Fedora 34 (x86-64). Basically llvm-tblgen crashes reliably:
FAILED: lib/Target/X86/X86GenDAGISel.inc cd /tmp/_update_lc/t && /tmp/_update_lc/t/bin/llvm-tblgen -gen-dag-isel -I /home/dave/ro_s/lp/llvm/lib/Target/X86 -I/tmp/_update_lc/t/include -I/home/dave/ro_s/lp/llvm/include -I /home/dave/ro_s/lp/llvm/lib/Target -omit-comments /home/dave/ro_s/lp/llvm/lib/Target/X86/X86.td --write-if-changed -o lib/Target/X86/X86GenDAGISel.inc -d lib/Target/X86/X86GenDAGISel.inc.d PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /tmp/_update_lc/t/bin/llvm-tblgen -gen-dag-isel -I /home/dave/ro_s/lp/llvm/lib/Target/X86 -I/tmp/_update_lc/t/include -I/home/dave/ro_s/lp/llvm/include -I /home/dave/ro_s/lp/llvm/lib/Target -omit-comments /home/dave/ro_s/lp/llvm/lib/Target/X86/X86.td --write-if-changed -o lib/Target/X86/X86GenDAGISel.inc -d lib/Target/X86/X86GenDAGISel.inc.d #0 0x000000000050b153 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/tmp/_update_lc/t/bin/llvm-tblgen+0x50b153) #1 0x00000000005094b2 llvm::sys::RunSignalHandlers() (/tmp/_update_lc/t/bin/llvm-tblgen+0x5094b2) #2 0x000000000050b4fa SignalHandler(int) Signals.cpp:0:0 #3 0x00007ffff7fa6a00 __restore_rt sigaction.c:0:0 #4 0x0000000000316a7d (/tmp/_update_lc/t/bin/llvm-tblgen+0x316a7d)
Good catch! Thanks
Mar 25 2021
Mar 24 2021
I've reverted this. If you need help debugging this, please let me know. Also, as a reminder, please see the attached build log from earlier in the conversation. Thanks!
Mar 23 2021
An auto-bisecting cron job has identified this change as a regression on Fedora 33 (x86-64). Can we get a quick fix or revert this? Here is the build output:
Mar 22 2021
Interesting. Thanks for looking into this and building on D98179. I'm sure that people will appreciate this change. :-)
Mar 20 2021
Adding -stdlib=libstdc++ fixes it. Clang can default to libcxx so if the C++ standard library matters then the test needs to be explicit.
The very first RUN line seems to fail. Here is the output, sans FileCheck:
Mar 19 2021
Mar 17 2021
Mar 16 2021
I've run out of time for today, but for the record, I think we should use slash as the canonical separator for the timing data file. The actual separator doesn't matter because these strings are never used as paths, just as keys into a dictionary. (Therefore any character would work.) This would let us harmonize the Unix and Windows timing data files.
Ah yes, of course. I've marked that test as unavailable on Window for now: 61ca706461c5e1edc18526c9ddc3250fe074ed94
Said differently, the Unix side seems to always run the lit tests from a fresh/clean setup, even for incremental builds. If Windows tests lit differently then ya, things will blow up.
That implies a different testing environment. How different is the Windows testing environment compared to Unix? Do you specifically have a custom testing setup?
Removed the commented only-failures and fixed a nit before committing.
Mar 15 2021
Might somebody be willing to sign off on this change (this week or next)? I'd like to cherry-pick it to Swift's LLVM branch. Thanks for all the feedback so far.
Mar 12 2021
I fixed the call to split as requested. Being unfamiliar with python, I didn't know that it supported keyword arguments / parameter labels. Thanks.
I've made all of the requested changes to date. Two notes:
Mar 10 2021
I'm downgrading libcxx as a reviewer to non-blocking because the latest patch no longer requires changes to their project.
I renamed the file variable as requested.
I believe I have addressed all of the feedback to date.