@tejohnson Thank you very much for landing!

Colleagues, could you help me with landing? @tejohnson has approved the patch (if I applied the suggestion as it was expected, thank you @tejohnson!)

Thank you @tejohnson I've applied the suggested changes.

@tejohnson Thank you for your opinion. I've renamed the function member into shouldEmitLTOSummary and extract the condition only. The code that changes the module flags is still inlined. The patch description was also edited to reflect these changes.

Colleagues, could you review this small non-functional change. After the TargetTruiple member has been extracted, it becomes clear that there is some code duplication in the BackendUtil.cpp source file. I think this is a good idea to eliminate this code duplication, isn't it?

All tests have been passed. Could anyone with the committer privileges help me with landing, please?

Thank you @tejohnson for the approve. If there are no objections from someone could you (or another committer) help me with the landing, please?

I see some code duplication on lines 1056-1065 and 1472-1481, I have a fix for this and going to open a new review after this patch will be landed.

Thank you very much for landing!

If there are no objections for this small patch, could someone with committer rights land it, please? Thank you.

@arsenm Thank you for the approve. If no one has any objections, could you help me with landing because I have no committer rights to the LLVM repository? Thank you.

All the failed tests on Windows are in the LLVM :: CodeGen/VE/Vector folder, I believe the tests aren't related to the changes introduces by the patch.

The linter warnings have been fixed.

Thank you @mstorsjo for landing.

Thank you @mstorsjo! I have no commit access, if you can commit this patch, it would be great. You can use the info from https://github.com/psamolysov-intel/llvm/commit/7467ea9a6a173829ab61693dd199ae0d94a0a787

x64 debian failed

@jhenderson Thank you, I missed the suggestion about the byte literal, sorry. Updated the test.

@mstorsjo I agree with you, we make some manipulations to get a library with a member named like this. Unfortunately, the member is not documented (or I cannot find the documentation) and it is difficult to build the right library using the Microsoft toolchain.

@jhenderson thank you for the review. I'm not an English native speaker, so some grammar may be bad, sorry. I've put the python script into the test itself as you suggested and added a few comments why this script is used at all.

@thieta Thank you for the approve. I have no commit right to the repository, so it would be great if someone with the commit rights lands the patch.

Thank you for the suggestion. I've added a python script to replace a section with /<XFGHASHMAP>/ and re-created a test to generate the library on the fly.

Thanks @jhenderson for the idea to use python to insert (or replace in my case) a section. I've updated the patch and added a test for the llvm-lib tool to list sections from a library with /<XFGHASHMAP>/. I've made a patch using the git diff -U8000 command and I'm not sure the binary file (the library for the test) has been uploaded well. If not, could you share with me the required command to attach the binary content to the patch?

Unfortunately, I have no idea how to create a library with the /<XFGHASHMAP>/ section. I'm trying to use /guard:cf directive for the compiler as well as for the linker with VS 2019 and 2022 but the generated library contains no such section. I've seen such section only in the standard libraries shipped with Microsoft Windows SDK for Windows 11 but (Kernel32.Lib, for example), as I understand, we cannot attach a 3rd party (Microsoft in this case) library to our project. I tried to create a DLL and interface library for it with a dependency from another DLL or a DLL that contain the DllMain entry point, no success. Any help is welcome.

Thank you for the comments. I'm going to revert the part about end->End renaming and add a test (or a few).