This was first shared as a patch here: https://github.com/llvm/llvm-project/issues/52714

Moved the test out.

I still need to run a few more external tests, like the ones mentioned in

In D133473#3787964, @tlively wrote:

Yeah the unrelated test failures can be ignored. Good point about our shuffle combine workaround, @penzn. Would you have time and resources to investigate whether we can remove the workaround now?

In D133473#3785568, @fanchenkong1 wrote:

Failed test is found on x64 windows, which seems to be related to mlir. Is there any action needed to fix the test?

A stray thought: we have disabled combining shuffles because it was producing precisely the masks this change seeks to eliminate, I am wondering if we can reenable some of those optimization based on this.

In D133473#3781884, @tlively wrote:

The code looks good, but I don't know much about native SIMD. Is this strictly better for engine-side codegen on all platforms? LGTM if so.

To me this makes since this applies to undefined indices and should not make any difference in case of valid ones.

Implemented locally instead

Because TLS data is stored a "passive" segment which has to be loaded using the memory.init instruction. (Both passive segments and this instruction are part of the bulk-memory proposal).

Oops, commented on outdated version (also had some issues with UI leaving repeated inline comments, sorry).

This change LGTM, can we also add some description of this process to developer docs? Anyone who would building LLVM on Windows is going to be hit by llvm-mt errors in current Visual Studio versions.

LGTM

Abandon in favor of D126873

I am personally building with this change already, for extra peace of mind :)

Looks like the feedback is addressed and overall this is a needed optimization. @tlively what do you think?

I think there is another dimension to this aside from project composition - intrinsics have a tendency to "interact" with their surroundings, and it better to capture the IR rather than the end result. Even if we can verify that simple calls produce instructions we expect, this might not hold true is the arguments change, or the call is in a different context. IR definitely gives more opportunities to test things through.

In D100717#2698680, @jdoerfert wrote:

I read through the code and I'm not sure if this is even a semantic change. I mean, can't we pick any
type to do the memory transfer expansion? If so, TBAA metadata as a heuristic should be totally fine.
We could also look at uses of the source and target pointers, for example. That said, we should write
in the lang ref that we do use the TBAA names for heuristics and they should be chosen to match the code/intent.

I am somewhat confused on performance vs correctness - D100717 refers to a miscompile, would adding this behavior also clear miscompiles?

Looks good to me.

Abandoned in favor of D89921

I think it works. We can keep "less than 4" check or keep it as is.

Fix broken diff.

Great, looks like I broke the diff.

Fix formatting in Writer.cpp.

In D89921#2346184, @vitalybuka wrote:

do we need to update some tests?

I had to edit the comment above, looks like I took snapshot from directory when I was reproducing build instructions, instead of actual test directory. Now the exe and base64 encoding above (in the gist as well) are correct and the test should pass.

Formatting; also instructions on building test image.

Another minor edit, I moved COFF test files for llvm-readobj to the directory where the rest of them are now.

Use write32le to set extended DLL characteristics.

I've started the discussion on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2020-March/139706.html

Expanding on my previous comment. In its current state yaml2obj is not aware of the section contents, and I think adding this functionality would be a bit more involved than the code we have in this review so far.

@ruiu can we separate enhancing yaml2obj from this change? I would be more than happy to help with implementing debug directory support as a separate change, to avoid making this change much more involved.

yaml2obj is capable of producing binary .rdata section (which would host CET bit) from hex, but not individual debug directories that would go into it. Looks like all the tests dealing wit debug directories are using pre-built binaries - codeview tests are a good example).

In D70606#1778998, @ruiu wrote:

Could you tell me about how you generated has_cet.exe? I wonder if there's a way to create an executable in the test instead of submitting a binary file to the repository.

Can you help me merge this? I don't have commit access.

Thank you!

Incorporate review feedback

Remove unused MinGW flag

Full(er) patch for the same change.