There is clearly some more work to do to get the cmake file to be correct, but was hoping to check this looked like the direction you thought looked right for adding this test, since there isn't an obvious example to follow.

I couldn't think of an example where you'd want to make sure all of the assigned categories were related to the command being used, instead of showing the option if at least one was related to it. Currently it hides the option as soon as any don't match, whereas it seems like you'd want to hide the option only if all categories don't match.

update

This is probably just a draft, but please let me know what you think

enable help

oops

oops

add release notes, docs mention, and test example

add release notes, docs mention, and test example

Rename LoadTy to SrcTy and StoreTy to DstTy

Yes, this header does everything

@aemerson are you happy with this test for approval and merge now?

bump? tagging some more people who seemed like possible reviewers. I realized my original list of candidates might have mostly been inactive people.

adding test

bump?

bump?

fix test

Looks similar to my previous patch (rG4a406d32e97b1748c4eed6674a2c1819b9cf98ea), so this makes sense to me.

I don't have a test, but it sounded like you did?

clang-format

Thanks!

The output looks to be missing a llvm.masked.gather.v2i64.v2p0i64 call. Did you remember to revert 0d74fd3fdf50? I can push a branch to github with this current commit, if that would be helpful.

bump

rebase on main

Need a test fix, but lgtm

fix another missed test update

rebase onto master

The complexity of this design appears to have been rendered mostly irrelevant by 141e845da5dda6743a09f858b4aec0133a931453, so only the new flag is needed, and not the new subclass.

The full reproducer is in the commit message on phabricator for this review, though I don't know how to link to the text of a commit specifically. Here's the text of that:

adding test

There doesn't seem to be a reason to make the VALGRIND_DISCARD_TRANSLATIONS call conditional. The macro is already a specific sequence of bytes (e.g. rol instructions) that are a no-op if valgrind is not running the particular segment of code inside its own JIT

It appears another subset of this might have been merged in https://reviews.llvm.org/D77767 also?

This looks like the bug I reported in https://bugs.llvm.org/show_bug.cgi?id=41629. Should I close it, or did you want to add that as a test?

On second thought, since the SHARED build is now fixed, there is no reason to disable it (and it helps eliminate more missing link problems).

Okay, the first problem is because add_llvm_library doesn't support STATIC, so we need to use llvm_add_library instead (though it is also fixed by adding the missing Support dependency). The second problem is also missing dependency (for CommonTableGen).

Reverted. Seems that something is going wrong with -DBUILD_SHARED_LIBS=ON with this.

LGTM, modulo comments from previous reviewer

needed for memmove too

I think with the move to newer C++ standards, some of the missing functionality in C could be replicated (or use the _WIN32 code paths for __CYGWIN__ in more places). I tried that for a bit, but it was pieces like struct sigaction, realpath, and getsid missing, which are very platform-specific.

I think this, and similar recent commits, are causing the shared library builds to fail some tests if this code gets linked into libLLVM.so: https://bugs.llvm.org/show_bug.cgi?id=48181. I assume it might actually a bug in ld (GNU Binutils for Ubuntu 2.34), as I don't understand the linker behavior there?

Thanks for identifying that. I think I can re-land just without that part of the test. It is not essential, I added it just to try to check all of the dwarf-related output.