Page MenuHomePhabricator
Feed Advanced Search

Today

davezarzycki added a comment to D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

If a lit invocation runs multiple test suites that contain identically named test files, is there any way to make an --xfail entry apply to only one of them?

Tue, Mar 2, 6:05 AM · Restricted Project
davezarzycki updated the diff for D97046: [lit] Generalize `early_tests`.

Let's rename EARLY_TESTS_THEN_BY_NAME while we're at it.

Tue, Mar 2, 5:22 AM · Restricted Project, Restricted Project
davezarzycki updated the diff for D97046: [lit] Generalize `early_tests`.

This is the generalized update as previously discussed.

Tue, Mar 2, 5:17 AM · Restricted Project, Restricted Project

Yesterday

davezarzycki added a comment to D97046: [lit] Generalize `early_tests`.

Ping. I'd like to fully generalize the recently introduced early_tests into test_phases. This will address earlier concerns and allow people to scale their test phasing with their maintenance goals/non-goals. For example, Swift's low-maintenance config would look like this:

Mon, Mar 1, 3:18 AM · Restricted Project, Restricted Project

Fri, Feb 26

davezarzycki added a comment to D97046: [lit] Generalize `early_tests`.

I've implemented the requested prefix matching but having done so, I'd like to request that we just replace early_tests with test_phases which is a dictionary of paths/path-prefixes to integers, where zero is the default phase and negative numbers represent early phases and positive numbers represent late stages. This gives users maximal flexibility.

Fri, Feb 26, 5:08 AM · Restricted Project, Restricted Project

Thu, Feb 25

davezarzycki added a comment to D97046: [lit] Generalize `early_tests`.

I feel like this should be handled by lit transparently, like recording the time it took to run each test last time, then somehow deciding on the new test run order based on that,

Thu, Feb 25, 7:23 AM · Restricted Project, Restricted Project
davezarzycki added a comment to D97046: [lit] Generalize `early_tests`.
In D97046#2585820, @yln wrote:

I also want to state that I am a bit concerned about feature creep and the the general usefulness of this effort.

  • Does shaving off 5% of test time for one project justify having it in upstream?
Thu, Feb 25, 5:15 AM · Restricted Project, Restricted Project

Wed, Feb 24

davezarzycki added inline comments to D97046: [lit] Generalize `early_tests`.
Wed, Feb 24, 4:38 AM · Restricted Project, Restricted Project
davezarzycki added a comment to D97046: [lit] Generalize `early_tests`.

It is both impractical and unwise to mark all of the non-compiler-crasher tests in Swift as "early". It's impractical because that's most of the tests. It's unwise because having more than a few tests in the early stage negates the benefit of the early stage itself.

Wed, Feb 24, 3:48 AM · Restricted Project, Restricted Project

Mon, Feb 22

davezarzycki added a comment to D97046: [lit] Generalize `early_tests`.

Could you clarify more what the benefit of running the tests later actually is? Is this intended to be useful in conjunction with something else? On the face of it, I'd expect people to run the full testsuite to completion, and then observe the full results. Ultimately, it doesn't matter whether a test runs first or last in this order for that case.

You want long running tests to run first and shorter one last as they will use to balance the imbalance from long running test. It's just to maximize the parallelism. If you have some medium to big tests running at the end, the risk is you are waiting for one core to finish while all the others are sitting idle. If you keep lots of small tests at the end, the cores that are idle will pick from it and hopefully reduce the imbalance.

I get the idea of running long tests early, but from observation, the vast majority of lit tests in the LLVM test suite are very similar in length, lasting less than a second. As such, it doesn't make any significant difference whether they are run late, or in the middle (as long as the long ones are run early). I would assume the same applies as much for these Swift tests as any other equivalent ones. I could see a case if we're suggesting that this feature is for a downstream test suite that is mostly comprised of long and slow tests (i.e. ones that take several seconds each), so that it's easier to mark the ones that are quick, but I don't think that's the case here?

Mon, Feb 22, 2:29 AM · Restricted Project, Restricted Project

Sat, Feb 20

davezarzycki added a comment to D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

Thanks. Fixed: 4550fdff2b2eec15143fac536e41ce967e522a3a

Sat, Feb 20, 6:45 AM · Restricted Project
davezarzycki committed rG4550fdff2b2e: [lit testing] "END." not "END:" (authored by davezarzycki).
[lit testing] "END." not "END:"
Sat, Feb 20, 6:44 AM
davezarzycki committed rG45d058e56d43: [lit] Add --xfail and --filter-out (inverse of --filter) (authored by davezarzycki).
[lit] Add --xfail and --filter-out (inverse of --filter)
Sat, Feb 20, 2:44 AM
davezarzycki closed D96662: [lit] Add --xfail and --filter-out (inverse of --filter).
Sat, Feb 20, 2:44 AM · Restricted Project
davezarzycki updated the diff for D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

I believe I have addressed all of the feedback to date.

Sat, Feb 20, 2:42 AM · Restricted Project

Fri, Feb 19

davezarzycki requested review of D97046: [lit] Generalize `early_tests`.
Fri, Feb 19, 5:33 AM · Restricted Project, Restricted Project
davezarzycki updated the diff for D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

I've renamed --skip to --filter-out. I prefer "out" to "not" because that matches the documentation for the command.

Fri, Feb 19, 2:41 AM · Restricted Project

Thu, Feb 18

davezarzycki added a comment to D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

Ping. Is anybody willing to sign off on this? There is clearly interest by those that maintain downstream repos to have something like --xfail and/or LIT_XFAIL. (I'm partial to the latter due to how my CI works.)

Thu, Feb 18, 4:18 AM · Restricted Project

Wed, Feb 17

davezarzycki added a comment to D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

If I might critique myself, I'm not sure that regular expression semantics are best for --xfail. One really wants and should use a precise list of some kind. Any thoughts on what that might look like? I'd lean toward a semicolon separated list.

A precise list would make sense. I'd use commas rather than semicolons, because semicolons are more likely to require shell escaping, I think (commas are less likely to).

In my experience, quotes solve most "escaping" problems, so what is used as a separator mostly doesn't matter as long as the character isn't used for variable expansion. Using the shell's statement separator is a good choice because shell users/programmers naturally avoid files with that character embedded in the name.

Actually, maybe we should just use multiple --xfail options, rather than a single one that takes a list. That way, the individual file names people use isn't relevant.

We can do that, but that won't work for LIT_XFAIL, so one would be forced to use LIT_OPTS and now we've come full circle back to the shell escaping problem.

Wed, Feb 17, 4:23 AM · Restricted Project
davezarzycki added a comment to D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

If I might critique myself, I'm not sure that regular expression semantics are best for --xfail. One really wants and should use a precise list of some kind. Any thoughts on what that might look like? I'd lean toward a semicolon separated list.

A precise list would make sense. I'd use commas rather than semicolons, because semicolons are more likely to require shell escaping, I think (commas are less likely to).

In my experience, quotes solve most "escaping" problems, so what is used as a separator mostly doesn't matter as long as the character isn't used for variable expansion. Using the shell's statement separator is a good choice because shell users/programmers naturally avoid files with that character embedded in the name.

Actually, maybe we should just use multiple --xfail options, rather than a single one that takes a list. That way, the individual file names people use isn't relevant.

Wed, Feb 17, 4:18 AM · Restricted Project
davezarzycki committed rG161e826c586e: [lit] Add "early_tests" config option (authored by davezarzycki).
[lit] Add "early_tests" config option
Wed, Feb 17, 3:33 AM
davezarzycki closed D96594: [lit] Add "early_tests" config option.
Wed, Feb 17, 3:33 AM · Restricted Project
davezarzycki added a comment to D96662: [lit] Add --xfail and --filter-out (inverse of --filter).
In D96662#2566903, @yln wrote:

I can get behind --skip (patch LGTM), but would a little help to understand when --xfail=path/to/test1;path/to/test2 would be useful (which workflow?). Thanks!

One example where it would be useful - in our downstream merge process, we may identify a test that has started failing due to an upstream bug. We could modify the test explicitly by adding XFAIL to the start of it, or we could add it to the build script that is used to build and test the changes before they are merged in. The --xfail option allows the latter to happen in such a way that when the issue is fixed by a later upstream change, we'll notice (due to the test starting to pass) and remove the option from the script, whereas with --skip, we won't notice (and thus lose the testing downstream the test gave us). I could imagine other cases along these lines too, where --xfail is superior to --skip.

Wed, Feb 17, 3:12 AM · Restricted Project

Tue, Feb 16

davezarzycki updated the diff for D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

After some thought, I think a list is better than a regex for --xfail. In contrast, having --skip take a regex makes sense because it is the opposite of --filter (like grep -v and grep respectively).

Tue, Feb 16, 9:41 AM · Restricted Project
davezarzycki added a comment to D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

If I might critique myself, I'm not sure that regular expression semantics are best for --xfail. One really wants and should use a precise list of some kind. Any thoughts on what that might look like? I'd lean toward a semicolon separated list.

Tue, Feb 16, 5:27 AM · Restricted Project
davezarzycki updated the diff for D96594: [lit] Add "early_tests" config option.

I believe I have addressed all of the feedback to date.

Tue, Feb 16, 3:36 AM · Restricted Project

Mon, Feb 15

davezarzycki added a comment to D96594: [lit] Add "early_tests" config option.

I'd like to take a look at this, but I have too many things on my plate today. I can probably make time tomorrow or Wednesday though, if you're happy to hold off until then?

Mon, Feb 15, 10:28 AM · Restricted Project
davezarzycki added inline comments to D96662: [lit] Add --xfail and --filter-out (inverse of --filter).
Mon, Feb 15, 8:54 AM · Restricted Project
davezarzycki added a comment to D95877: [analyzer] Fix static_cast on pointer-to-member handling.

The test seems to be broken on Fedora 33 (x86-64 with clang-11):

XPASS: Clang :: Analysis/reinterpret-cast-pointer-to-member.cpp (6531 of 74360)
******************** TEST 'Clang :: Analysis/reinterpret-cast-pointer-to-member.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem /tmp/_update_lc/r/lib/clang/13.0.0/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -analyzer-checker=core,debug.ExprInspection -verify /home/dave/ro_s/lp/clang/test/Analysis/reinterpret-cast-pointer-to-member.cpp
--
Exit Code: 0
Mon, Feb 15, 6:24 AM · Restricted Project
davezarzycki retitled D96662: [lit] Add --xfail and --filter-out (inverse of --filter) from [lit] Add --skip (inverse of --filter) to [lit] Add --skip (inverse of --filter) and `--xfail`.
Mon, Feb 15, 6:20 AM · Restricted Project
davezarzycki updated the diff for D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

I agree that both --skip (a.k.a. LIT_SKIP) and --xfail (a.k.a. LIT_XFAIL) are independently useful so I've updated the patch.

Mon, Feb 15, 6:19 AM · Restricted Project

Sun, Feb 14

davezarzycki updated the diff for D96662: [lit] Add --xfail and --filter-out (inverse of --filter).

Add docs not included in the first diff.

Sun, Feb 14, 4:24 AM · Restricted Project
davezarzycki retitled D96662: [lit] Add --xfail and --filter-out (inverse of --filter) from ' to [lit] Add --skip (inverse of --filter).
Sun, Feb 14, 4:22 AM · Restricted Project
davezarzycki requested review of D96662: [lit] Add --xfail and --filter-out (inverse of --filter).
Sun, Feb 14, 4:19 AM · Restricted Project
davezarzycki retitled D96594: [lit] Add "early_tests" config option from [lit] Add "slowest_tests" config option to [lit] Add "early_tests" config option.
Sun, Feb 14, 3:42 AM · Restricted Project

Sat, Feb 13

davezarzycki updated the diff for D96594: [lit] Add "early_tests" config option.

I think I have addressed all of the feedback to date. Thank you @jdenny

Sat, Feb 13, 9:28 AM · Restricted Project
davezarzycki added a comment to D96594: [lit] Add "early_tests" config option.

I can rename the variable if you want. That being said, this proposal is a mere refinement to the "run early" feature. And unless I'm missing something, the "run early" feature lacks documentation and tests. Are you asking me to fix that? I'd also like to point out that timing tests are surprisingly difficult to write if one cares about not being sensitive to the performance of the underlying hardware or how busy (or not) the machine is.

Sat, Feb 13, 2:53 AM · Restricted Project

Fri, Feb 12

davezarzycki requested review of D96594: [lit] Add "early_tests" config option.
Fri, Feb 12, 5:00 AM · Restricted Project

Jan 24 2021

davezarzycki committed rG1bc8daba4fa3: Fix x86 exegesis tests after c042aff8860df3cad2b274bf0a495e83ae36ddee (authored by davezarzycki).
Fix x86 exegesis tests after c042aff8860df3cad2b274bf0a495e83ae36ddee
Jan 24 2021, 5:51 AM
davezarzycki closed D95287: Fix x86 exegesis tests after c042aff8860df3cad2b274bf0a495e83ae36ddee.
Jan 24 2021, 5:51 AM · Restricted Project

Jan 23 2021

davezarzycki updated the summary of D95287: Fix x86 exegesis tests after c042aff8860df3cad2b274bf0a495e83ae36ddee.
Jan 23 2021, 8:12 AM · Restricted Project
davezarzycki requested review of D95287: Fix x86 exegesis tests after c042aff8860df3cad2b274bf0a495e83ae36ddee.
Jan 23 2021, 8:07 AM · Restricted Project

Jan 14 2021

davezarzycki added a comment to D94656: [libcxx testing] Fix UB in tests for std::lock_guard.

I appreciate that you're trying to make this be defined behavior, but I honestly don't know why this is UB. I can't think of or find a platform where the underlying OS "trylock" routine would have UB when called on the same thread that owns the lock already. Can somebody with access to the C++ standard provide any hint to why the standard wants this to be UB?

Jan 14 2021, 2:51 AM · Restricted Project

Jan 13 2021

davezarzycki added a reverting change for rGe5553b9a6ab9: [dsymutil] Warn on timestmap mismatch between object file and debug map: rGc6e341c89957: Revert "[dsymutil] Warn on timestmap mismatch between object file and debug map".
Jan 13 2021, 4:24 AM
davezarzycki committed rGc6e341c89957: Revert "[dsymutil] Warn on timestmap mismatch between object file and debug map" (authored by davezarzycki).
Revert "[dsymutil] Warn on timestmap mismatch between object file and debug map"
Jan 13 2021, 4:24 AM
davezarzycki added a reverting change for D94536: [dsymutil] Warn on timestmap mismatch between object file and debug map: rGc6e341c89957: Revert "[dsymutil] Warn on timestmap mismatch between object file and debug map".
Jan 13 2021, 4:24 AM · Restricted Project
davezarzycki added a comment to D94536: [dsymutil] Warn on timestmap mismatch between object file and debug map.

The test is just broken. Tests are not allowed to modify the source as they run. I'm sorry but I need to revert this. If you need help testing on a read-only source checkout, please let me know.

Jan 13 2021, 4:19 AM · Restricted Project

Dec 18 2020

davezarzycki committed rG430d5d842947: [LLDB] Unbreak the build after recent clang changes (authored by davezarzycki).
[LLDB] Unbreak the build after recent clang changes
Dec 18 2020, 4:55 AM

Dec 14 2020

davezarzycki added a comment to D91488: Consider reference, pointer, and pointer-to-membber TemplateArguments to be different if they have different types..

Thanks. I just verified that reverting this change fixes the second stage regression and was about to commit the revert.

Dec 14 2020, 5:12 AM · Restricted Project
davezarzycki added a comment to D91488: Consider reference, pointer, and pointer-to-membber TemplateArguments to be different if they have different types..

This change is causing second stage build failures on Fedora 33 (x86-64). I'll probably revert this soon, but in the mean time, here is a snippet of the build output:

FAILED: lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkGeneric.cpp.o
/p/tllvm/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/ExecutionEngine/JITLink -I/home/dave/ro_s/lp/llvm/lib/ExecutionEngine/JITLink -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 -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 -O2   -march=skylake -fno-vectorize -fno-slp-vectorize -fno-tree-slp-vectorize -fno-exceptions -fno-rtti -UNDEBUG -std=c++14 -MD -MT lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkGeneric.cpp.o -MF lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkGeneric.cpp.o.d -o lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkGeneric.cpp.o -c /home/dave/ro_s/lp/llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.cpp
In file included from /home/dave/ro_s/lp/llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.cpp:13:
/home/dave/ro_s/lp/llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.h:150:18: error: invalid operands to binary expression ('llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' and 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>')
    for (auto *B : G.blocks()) {
                 ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/APInt.h:2037:13: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'uint64_t' (aka 'unsigned long') for 1st argument
inline bool operator!=(uint64_t V1, const APInt &V2) { return V2 != V1; }
            ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/APSInt.h:340:13: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'int64_t' (aka 'long') for 1st argument
inline bool operator!=(int64_t V1, const APSInt &V2) { return V2 != V1; }
            ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/StringRef.h:904:15: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'llvm::StringRef' for 1st argument
  inline bool operator!=(StringRef LHS, StringRef RHS) { return !(LHS == RHS); }
              ^
/p/tllvm/bin/../include/c++/v1/system_error:419:1: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'const std::error_code' for 1st argument
operator!=(const error_code& __x, const error_code& __y) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/system_error:424:1: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'const std::error_code' for 1st argument
operator!=(const error_code& __x, const error_condition& __y) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/system_error:429:1: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'const std::error_condition' for 1st argument
operator!=(const error_condition& __x, const error_code& __y) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/system_error:434:1: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'const std::error_condition' for 1st argument
operator!=(const error_condition& __x, const error_condition& __y) _NOEXCEPT
^
/home/dave/ro_s/lp/llvm/include/llvm/Support/Alignment.h:262:13: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'llvm::Align' for 1st argument
inline bool operator!=(Align Lhs, uint64_t Rhs) {
            ^
/home/dave/ro_s/lp/llvm/include/llvm/Support/Alignment.h:287:13: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'llvm::MaybeAlign' for 1st argument
inline bool operator!=(MaybeAlign Lhs, uint64_t Rhs) {
            ^
/home/dave/ro_s/lp/llvm/include/llvm/Support/Alignment.h:295:13: note: candidate function not viable: no known conversion from 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>' to 'llvm::Align' for 1st argument
inline bool operator!=(Align Lhs, Align Rhs) {
            ^
/p/tllvm/bin/../include/c++/v1/utility:584:1: note: candidate template ignored: could not match 'pair' against 'nested_collection_iterator'
operator!=(const pair<_T1,_T2>& __x, const pair<_T1,_T2>& __y)
^
/p/tllvm/bin/../include/c++/v1/iterator:818:1: note: candidate template ignored: could not match 'reverse_iterator' against 'nested_collection_iterator'
operator!=(const reverse_iterator<_Iter1>& __x, const reverse_iterator<_Iter2>& __y)
^
/p/tllvm/bin/../include/c++/v1/iterator:1040:1: note: candidate template ignored: could not match 'istream_iterator' against 'nested_collection_iterator'
operator!=(const istream_iterator<_Tp, _CharT, _Traits, _Distance>& __x,
^
/p/tllvm/bin/../include/c++/v1/iterator:1151:6: note: candidate template ignored: could not match 'istreambuf_iterator' against 'nested_collection_iterator'
bool operator!=(const istreambuf_iterator<_CharT,_Traits>& __a,
     ^
/p/tllvm/bin/../include/c++/v1/iterator:1274:1: note: candidate template ignored: could not match 'move_iterator' against 'nested_collection_iterator'
operator!=(const move_iterator<_Iter1>& __x, const move_iterator<_Iter2>& __y)
^
/p/tllvm/bin/../include/c++/v1/iterator:1650:1: note: candidate template ignored: could not match '__wrap_iter' against 'nested_collection_iterator'
operator!=(const __wrap_iter<_Iter1>& __x, const __wrap_iter<_Iter2>& __y) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/iterator:1682:1: note: candidate template ignored: could not match '__wrap_iter' against 'nested_collection_iterator'
operator!=(const __wrap_iter<_Iter1>& __x, const __wrap_iter<_Iter1>& __y) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/tuple:1185:1: note: candidate template ignored: could not match 'tuple' against 'nested_collection_iterator'
operator!=(const tuple<_Tp...>& __x, const tuple<_Up...>& __y)
^
/p/tllvm/bin/../include/c++/v1/memory:1713:6: note: candidate template ignored: could not match 'allocator' against 'nested_collection_iterator'
bool operator!=(const allocator<_Tp>&, const allocator<_Up>&) _NOEXCEPT {return false;}
     ^
/p/tllvm/bin/../include/c++/v1/memory:2642:1: note: candidate template ignored: could not match 'unique_ptr' against 'nested_collection_iterator'
operator!=(const unique_ptr<_T1, _D1>& __x, const unique_ptr<_T2, _D2>& __y) {return !(__x == __y);}
^
/p/tllvm/bin/../include/c++/v1/memory:2689:1: note: candidate template ignored: could not match 'unique_ptr' against 'nested_collection_iterator'
operator!=(const unique_ptr<_T1, _D1>& __x, nullptr_t) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/memory:2697:1: note: candidate template ignored: could not match 'unique_ptr' against 'nested_collection_iterator'
operator!=(nullptr_t, const unique_ptr<_T1, _D1>& __x) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/memory:4082:1: note: candidate template ignored: could not match 'shared_ptr' against 'nested_collection_iterator'
operator!=(const shared_ptr<_Tp>& __x, const shared_ptr<_Up>& __y) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/memory:4144:1: note: candidate template ignored: could not match 'shared_ptr' against 'nested_collection_iterator'
operator!=(const shared_ptr<_Tp>& __x, nullptr_t) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/memory:4152:1: note: candidate template ignored: could not match 'shared_ptr' against 'nested_collection_iterator'
operator!=(nullptr_t, const shared_ptr<_Tp>& __x) _NOEXCEPT
^
/p/tllvm/bin/../include/c++/v1/functional:2599:1: note: candidate template ignored: could not match 'function' against 'nested_collection_iterator'
operator!=(const function<_Rp(_ArgTypes...)>& __f, nullptr_t) _NOEXCEPT {return (bool)__f;}
^
/p/tllvm/bin/../include/c++/v1/functional:2604:1: note: candidate template ignored: could not match 'function' against 'nested_collection_iterator'
operator!=(nullptr_t, const function<_Rp(_ArgTypes...)>& __f) _NOEXCEPT {return (bool)__f;}
^
/p/tllvm/bin/../include/c++/v1/string_view:664:6: note: candidate template ignored: could not match 'basic_string_view' against 'nested_collection_iterator'
bool operator!=(basic_string_view<_CharT, _Traits> __lhs, basic_string_view<_CharT, _Traits> __rhs) _NOEXCEPT
     ^
/p/tllvm/bin/../include/c++/v1/string_view:673:6: note: candidate template ignored: could not match 'basic_string_view' against 'nested_collection_iterator'
bool operator!=(basic_string_view<_CharT, _Traits> __lhs,
     ^
/p/tllvm/bin/../include/c++/v1/string_view:683:6: note: candidate template ignored: could not match 'basic_string_view' against 'nested_collection_iterator'
bool operator!=(typename common_type<basic_string_view<_CharT, _Traits> >::type __lhs,
     ^
/p/tllvm/bin/../include/c++/v1/string:571:6: note: candidate template ignored: could not match 'fpos' against 'nested_collection_iterator'
bool operator!=(const fpos<_StateT>& __x, const fpos<_StateT>& __y)
     ^
/p/tllvm/bin/../include/c++/v1/string:4072:1: note: candidate template ignored: could not match 'basic_string' against 'nested_collection_iterator'
operator!=(const basic_string<_CharT,_Traits,_Allocator>& __lhs,
^
/p/tllvm/bin/../include/c++/v1/string:4081:1: note: candidate template ignored: could not match 'const _CharT *' against 'llvm::jitlink::LinkGraph::nested_collection_iterator<llvm::pointee_iterator<std::__wrap_iter<const std::unique_ptr<llvm::jitlink::Section> *>, llvm::jitlink::Section>, llvm::detail::DenseSetImpl<llvm::jitlink::Block *, llvm::DenseMap<llvm::jitlink::Block *, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::jitlink::Block *>, llvm::detail::DenseSetPair<llvm::jitlink::Block *>>, llvm::DenseMapInfo<llvm::jitlink::Block *>>::Iterator, llvm::jitlink::Block *, &llvm::jitlink::LinkGraph::getSectionBlocks>'
operator!=(const _CharT* __lhs,
^
/p/tllvm/bin/../include/c++/v1/string:4090:1: note: candidate template ignored: could not match 'basic_string' against 'nested_collection_iterator'
operator!=(const basic_string<_CharT, _Traits, _Allocator>& __lhs,
^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/Optional.h:315:16: note: candidate template ignored: could not match 'Optional' against 'nested_collection_iterator'
constexpr bool operator!=(const Optional<T> &X, const Optional<U> &Y) {
               ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/Optional.h:352:16: note: candidate template ignored: could not match 'Optional' against 'nested_collection_iterator'
constexpr bool operator!=(const Optional<T> &X, NoneType) {
               ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/Optional.h:357:16: note: candidate template ignored: could not match 'Optional' against 'nested_collection_iterator'
constexpr bool operator!=(NoneType, const Optional<T> &X) {
               ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/Optional.h:408:16: note: candidate template ignored: could not match 'Optional' against 'nested_collection_iterator'
constexpr bool operator!=(const Optional<T> &X, const T &Y) {
               ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/Optional.h:413:16: note: candidate template ignored: could not match 'Optional' against 'nested_collection_iterator'
constexpr bool operator!=(const T &X, const Optional<T> &Y) {
               ^
/p/tllvm/bin/../include/c++/v1/array:381:1: note: candidate template ignored: could not match 'array' against 'nested_collection_iterator'
operator!=(const array<_Tp, _Size>& __x, const array<_Tp, _Size>& __y)
^
/p/tllvm/bin/../include/c++/v1/vector:3346:1: note: candidate template ignored: could not match 'vector' against 'nested_collection_iterator'
operator!=(const vector<_Tp, _Allocator>& __x, const vector<_Tp, _Allocator>& __y)
^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/ArrayRef.h:541:15: note: candidate template ignored: could not match 'ArrayRef' against 'nested_collection_iterator'
  inline bool operator!=(ArrayRef<T> LHS, ArrayRef<T> RHS) {
              ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/ArrayRef.h:546:15: note: candidate template ignored: could not match 'SmallVectorImpl' against 'nested_collection_iterator'
  inline bool operator!=(SmallVectorImpl<T> &LHS, ArrayRef<T> RHS) {
              ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/DenseMap.h:704:6: note: candidate template ignored: could not match 'DenseMapBase' against 'nested_collection_iterator'
bool operator!=(
     ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/DenseSet.h:251:6: note: candidate template ignored: could not match 'DenseSetImpl' against 'nested_collection_iterator'
bool operator!=(const DenseSetImpl<ValueT, MapTy, ValueInfoT> &LHS,
     ^
/p/tllvm/bin/../include/c++/v1/map:1614:1: note: candidate template ignored: could not match 'map' against 'nested_collection_iterator'
operator!=(const map<_Key, _Tp, _Compare, _Allocator>& __x,
^
/p/tllvm/bin/../include/c++/v1/map:2199:1: note: candidate template ignored: could not match 'multimap' against 'nested_collection_iterator'
operator!=(const multimap<_Key, _Tp, _Compare, _Allocator>& __x,
^
/p/tllvm/bin/../include/c++/v1/set:918:1: note: candidate template ignored: could not match 'set' against 'nested_collection_iterator'
operator!=(const set<_Key, _Compare, _Allocator>& __x,
^
/p/tllvm/bin/../include/c++/v1/set:1445:1: note: candidate template ignored: could not match 'multiset' against 'nested_collection_iterator'
operator!=(const multiset<_Key, _Compare, _Allocator>& __x,
^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/PointerUnion.h:241:6: note: candidate template ignored: could not match 'PointerUnion' against 'nested_collection_iterator'
bool operator!=(PointerUnion<PTs...> lhs, PointerUnion<PTs...> rhs) {
     ^
/home/dave/ro_s/lp/llvm/include/llvm/ADT/iterator.h:145:8: note: candidate function not viable: no known conversion from 'nested_collection_iterator<...>' to 'const nested_collection_iterator<...>' for 1st argument
  bool operator!=(const DerivedT &RHS) const {
       ^
Dec 14 2020, 2:49 AM · Restricted Project

Nov 24 2020

davezarzycki added a comment to D92028: Fix driver test from e16c0a9a689719.

This is breaking building on Fedora 33 (x86-64). Can we revert this or get a quick fix?

Nov 24 2020, 3:41 PM · Restricted Project

Nov 13 2020

davezarzycki committed rG5a327f333763: Revert "[NFC] Move code between functions as a preparation step for further… (authored by davezarzycki).
Revert "[NFC] Move code between functions as a preparation step for further…
Nov 13 2020, 7:53 AM
davezarzycki added a reverting change for rG08016ac32b74: [NFC] Move code between functions as a preparation step for further improvement: rG5a327f333763: Revert "[NFC] Move code between functions as a preparation step for further….
Nov 13 2020, 7:53 AM

Nov 9 2020

davezarzycki updated the diff for D91093: [X86 and PPC] Tune SelectionDAG CTPOP emulation via TLI hook.

Fixed the malformed diff/patch.

Nov 9 2020, 10:57 AM · Restricted Project
davezarzycki requested review of D91093: [X86 and PPC] Tune SelectionDAG CTPOP emulation via TLI hook.
Nov 9 2020, 10:55 AM · Restricted Project
davezarzycki committed rGa41ea782c8e1: [SelectionDAG] Enable CTPOP optimization fine tuning (authored by davezarzycki).
[SelectionDAG] Enable CTPOP optimization fine tuning
Nov 9 2020, 10:50 AM
davezarzycki closed D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.
Nov 9 2020, 10:49 AM · Restricted Project
davezarzycki updated the diff for D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

Removed the comment about x86 bias now that more testing exists.

Nov 9 2020, 8:07 AM · Restricted Project
davezarzycki updated the diff for D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

I've rebased and pre-committed AArch64 and PPC tests. This is still NFC.

Nov 9 2020, 8:05 AM · Restricted Project
davezarzycki committed rG57e46e712349: [SelectionDAG] NFC: Hoist is legal check (authored by davezarzycki).
[SelectionDAG] NFC: Hoist is legal check
Nov 9 2020, 7:55 AM
davezarzycki committed rGd631e5240c9a: [testing] Add exhaustive ULT/UGT vector CTPOP to AArch64 and PPC (authored by davezarzycki).
[testing] Add exhaustive ULT/UGT vector CTPOP to AArch64 and PPC
Nov 9 2020, 7:34 AM

Nov 6 2020

davezarzycki committed rG179d91b37631: [lld testing] Unbreak read-only source builds (authored by davezarzycki).
[lld testing] Unbreak read-only source builds
Nov 6 2020, 4:15 AM

Nov 5 2020

davezarzycki added a comment to D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

Rebase. No change.

The patch now has no test suite impact because all of the vector CTPOP tests that should be eliminated before code gen have been removed on trunk/master.

Is this a no-functional-change patch for cases that are not reduced in IR?

Nov 5 2020, 2:25 AM · Restricted Project

Oct 29 2020

davezarzycki committed rG075f661d01f8: [lldb] Unbreak the build after a recent PowerPC change (authored by davezarzycki).
[lldb] Unbreak the build after a recent PowerPC change
Oct 29 2020, 2:57 AM

Oct 28 2020

davezarzycki updated the diff for D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

Rebase. No change.

Oct 28 2020, 9:33 AM · Restricted Project
davezarzycki committed rG305d18a04b8c: [x86 testing] NFC: remove a few needless vector popcnt tests (authored by davezarzycki).
[x86 testing] NFC: remove a few needless vector popcnt tests
Oct 28 2020, 4:57 AM
davezarzycki committed rG419168d93819: [testing] Add missing REQUIRES: asserts (authored by davezarzycki).
[testing] Add missing REQUIRES: asserts
Oct 28 2020, 3:16 AM

Oct 27 2020

davezarzycki added a comment to D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

Hi @spatel – We can certainly remove the code gen tests that should have been handled by earlier optimization passes. Thanks for working on those. :-)

As to the use case, I have AVX512 machines without BITALG/VPOPCNTDQ and a program that is doing hamming distance checks in critical sections. I.e. lots of low numbered "popcnt(x) < smallNumber" kind of checks that would be more efficiently implemented as a chain of legal "x & (x - 1)" instructions instead of the current/custom POPCNT emulation logic. This is especially true on my Knights Landing test box, which lacks AVX512BW and falling back to AVX2 to emulate VPOPCNTDQ is quite expensive.

Ok - I have no doubts that there are cases we can optimize better. It would be great to see 1 or more reduced examples of these code patterns in source code. That way, we can confirm that we're not still missing any pre-codegen optimizations . Can you file a bug to show that?

Oct 27 2020, 6:35 AM · Restricted Project
davezarzycki added a comment to D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

Hi @spatel – We can certainly remove the code gen tests that should have been handled by earlier optimization passes. Thanks for working on those. :-)

Oct 27 2020, 3:20 AM · Restricted Project

Oct 23 2020

davezarzycki updated the diff for D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

Hi @craig.topper and @spatel – I'd like to break this patch into two parts. This patch is the first part: the mechanism that enables targets to tune the length of "x & (x - 1)" chains used to emulate unsigned greater-than/less-than comparisons against a CTPOP result.

Oct 23 2020, 8:07 AM · Restricted Project

Oct 22 2020

davezarzycki added a comment to D89976: [ValueTracking] add range limits for ctpop.

Thanks. Unless less I missed it, we should also add the upper range for count leading/trailing zero too.

Oct 22 2020, 12:42 PM · Restricted Project
davezarzycki added a comment to D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

@spatel -- Here is the bug you requested: https://bugs.llvm.org/show_bug.cgi?id=47949

Oct 22 2020, 11:32 AM · Restricted Project
davezarzycki updated the diff for D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

Updated CTPOP emulation cost heuristics and test diffs so people can see the fallout. Overall, I tried to aim for the same or fewer number of instructions as before, which should be a win because chains of "x & (x - 1)" don't require memory loads, unlike actual CTPOP emulation.

Oct 22 2020, 11:21 AM · Restricted Project
davezarzycki added a comment to D89976: [ValueTracking] add range limits for ctpop.

FYI -- I'm not sure if it'll change the test impact of this patch, but I did commit a bunch of x86 vector popcnt tests to the repository this morning.

Oct 22 2020, 11:08 AM · Restricted Project
davezarzycki added inline comments to D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.
Oct 22 2020, 10:49 AM · Restricted Project
davezarzycki added a comment to D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.

Also, this patch ought to be refined to optimize something like CTPOP(x) > 62 into CTPOP(NOT(x)) <= 2 or a chain of (x | (x + 1)) and a final comparison against a mask value instead of zero (whatever is more efficient).

Oct 22 2020, 5:50 AM · Restricted Project
davezarzycki requested review of D89952: [SelectionDAG] Enable CTPOP optimization fine tuning.
Oct 22 2020, 5:38 AM · Restricted Project
davezarzycki committed rG8556f38b0d62: [x86 testing] NFC: Create exhaustive vector popcnt ULT/UGT tests (authored by davezarzycki).
[x86 testing] NFC: Create exhaustive vector popcnt ULT/UGT tests
Oct 22 2020, 4:59 AM

Oct 21 2020

davezarzycki committed rG87f6de72bcd3: [clang testing] Fix a read-only source build system failure (authored by davezarzycki).
[clang testing] Fix a read-only source build system failure
Oct 21 2020, 5:08 AM
davezarzycki added a comment to D89500: Fix the error message with -fbasic-block-sections=list=<filename>.

I think I fixed it. Please verify: 87f6de72bcd346bbbf468e9f9a0e9d1bbf0630a9

Oct 21 2020, 5:08 AM · Restricted Project
davezarzycki added a comment to D89500: Fix the error message with -fbasic-block-sections=list=<filename>.

A git bisect run blamed this patch for breaking the ability to build with a read-only source tree. Can we revert this or make a quick fix?

Oct 21 2020, 4:50 AM · Restricted Project

Oct 19 2020

davezarzycki added a comment to D89346: [SelectionDAG][X86] Enable SimplifySetCC CTPOP transforms for vector splats.

The tests I want to add shouldn't be affected by this patch. They're for a subsequent patch that I want to contribute that refines this patch.

Oct 19 2020, 7:33 AM · Restricted Project

Sep 27 2020

davezarzycki added a comment to D88123: Add the ability to write 'target stop-hooks' in Python.

Hi Jim, this change broke my Fedora 33 Linux (x86) box. Do you think we can get a quick fix or revert this?

Sep 27 2020, 2:48 AM · Restricted Project

Sep 2 2020

davezarzycki added a comment to D86497: [lldb] Add reproducer verifier.

And just to be clear, the source directory in my setup is in the home directory. My cron job / "bot" build just builds in /tmp.

Sep 2 2020, 3:49 AM · Restricted Project, Restricted Project
davezarzycki added a comment to D86497: [lldb] Add reproducer verifier.

Line 18 fails: %lldb -x -b --replay %t.repro >> %t.txt 2>&1

error: reproducer replay failed:
warning: home directory '/home/dave' not in VFS
Sep 2 2020, 3:43 AM · Restricted Project, Restricted Project

Sep 1 2020

davezarzycki added a comment to D86497: [lldb] Add reproducer verifier.

Hello. I have an auto-bisecting multi-stage bot that has identified this change as breaking release (without assertions) testing on Fedora 33 x86-64. Can we get a quick fix or revert this change for now?

Sep 1 2020, 2:31 AM · Restricted Project, Restricted Project

Aug 27 2020

davezarzycki added a comment to D86354: [ADT] Make Optional a literal type..

This seems to only allow empty optionals to be constexpr. Should the non-default constructor also be constexpr?

The reason I implemented the minimal thing was that I wasn't sure how far I should go. In a Swift PR, @davezarzycki raised the point about constexpr potentially leading to longer compile times even when not used for compile-time computation. I asked some folks internally at Apple and the response I got was along the lines of, "That's surprising... If that's actually the case, it should be reported as a Clang bug". I haven't been able to dedicate time to benchmarking the impact of constexpr on compile time... Since Optional is a currency type, I wasn't sure if people would object to more methods being marked constexpr. In principle, I don't see any reason for any method on Optional to not be constexpr.

That upstream thread doesn't look like it's talking about the impact of constexpr in non-constexpr contexts. Yes, making a variable constexpr when you don't need it to be can have negative compile time consequences - but in Clang I don't believe (again, can be bugs, but it doesn't sound like that swift thread is suggesting the existence of such bugs) a constexpr function called in a non-constexpr context is handled any differently than if it were a non-constexpr function. (GCC is different in this regard and does try to do constexpr things in non-constexpr contexts, though unclear how hard it tries before bailing out to the non-constexpr handling)

Aug 27 2020, 4:02 AM · Restricted Project

Aug 24 2020

davezarzycki added a comment to D84013: Correctly emit dwoIDs after ASTFileSignature refactoring (D81347).

Not fighting with how lit, FileCheck, and shell input/output work would help here:

Aug 24 2020, 4:47 AM · Restricted Project
davezarzycki added a comment to D84013: Correctly emit dwoIDs after ASTFileSignature refactoring (D81347).

I have an auto-bisecting cron job that has identified the "reland" as breaking the test suite on Fedora 32 (x86). Is there a quick fix or can we revert the reland?

Aug 24 2020, 3:52 AM · Restricted Project

Aug 20 2020

davezarzycki added a comment to D86120: [NFC][llvm] Make the constructors of `ElementCount` private..

Why were static "get" methods preferred over simply marking the constructor explicit? For example, if the constructor is marked explicit, then this is what users see:

Aug 20 2020, 2:53 AM · Restricted Project

Aug 18 2020

davezarzycki added inline comments to D82276: Make ninja smart console builds more pretty.
Aug 18 2020, 4:19 AM · Restricted Project

Aug 11 2020

davezarzycki committed rGef0c0844fef6: Add missing `-o -` to a recent test (authored by davezarzycki).
Add missing `-o -` to a recent test
Aug 11 2020, 3:00 AM

Jul 31 2020

davezarzycki added a comment to D82822: [OpenMP][FIX] Consistently use OpenMPIRBuilder if requested.

Hello, I have a twice-daily auto-bisecting multi-stage cron job running on Fedora 32 (x86-64) that has identified this commit as failing my first stage test (release + no asserts). Is this expected? Can we get a quick fix or revert this?

Jul 31 2020, 2:16 AM · Restricted Project

Jul 22 2020

davezarzycki added a comment to D81728: [InstCombine] Add target-specific inst combining.

I have a multi-stage, auto-git-bisecting bot that has identifying this commit as the source of a regression on Fedora 32 (x86-64). This commit broke my first stage test (release, no asserts). Might a quick fix happen or do we need to revert this?

Jul 22 2020, 5:26 PM · Restricted Project, Restricted Project, Restricted Project

Jul 14 2020

GitHub <noreply@github.com> committed rG50f2644b8b61: Merge pull request #1337 from davezarzycki/read_only_source_fix (authored by davezarzycki).
Merge pull request #1337 from davezarzycki/read_only_source_fix
Jul 14 2020, 4:54 PM
davezarzycki committed rGb5e3cfa6995b: [testing] Cherry-pick part of c90d38e4b9bb84a53b65ce1c136e04df77bfd094 (authored by davezarzycki).
[testing] Cherry-pick part of c90d38e4b9bb84a53b65ce1c136e04df77bfd094
Jul 14 2020, 4:54 PM
GitHub <noreply@github.com> committed rGb0e15576aa12: Merge pull request #764 from davezarzycki/pr764 (authored by davezarzycki).
Merge pull request #764 from davezarzycki/pr764
Jul 14 2020, 4:22 PM
davezarzycki committed rG0ff636a6ec75: [Testing] Unbreak aarch64 tests that assume darwin (authored by davezarzycki).
[Testing] Unbreak aarch64 tests that assume darwin
Jul 14 2020, 4:22 PM

Jul 12 2020

davezarzycki added a comment to D82085: [TRE] allow TRE for non-capturing calls..

Hello. I have an auto-bisecting multi-stage bot that is failing on two after this change. Can we please revert this or commit a quick fix?

Jul 12 2020, 2:43 AM · Restricted Project, Restricted Project

Jul 4 2020

davezarzycki committed rGe56e96a26426: [libcxx testing] Remove ALLOW_RETRIES from another test (authored by davezarzycki).
[libcxx testing] Remove ALLOW_RETRIES from another test
Jul 4 2020, 7:32 AM