python3kgae added a comment. In D133993#3816526 <https://reviews.llvm.org/D133993#3816526>, @efriedma wrote:
> Why are we using different mechanisms for global constructors in "libraries" > vs. other code? If we need a mechanism in LLVM already, we might as well use > it all the time? For library, even though we could inline all constructors for entry functions in the library, the exported functions which is not entry function could also require the constructors to be called in the entry function after linking. So we cannot remove the global variable for the constructors in library. For non-library cases, there should be only 1 entry function and the constructors are already called in the entry function. Keeping the global variable for the constructors will make the global variable has more than 1 store in some case which will disable some optimization opportunity. Also, backends might call the constructors again because the global variable still exists to mark the constructors. Then we go to the question of why call constructors in clang codeGen. The reason for that is the old version of DXIL does not allow function calls. Call constructors in clang codeGen could help to remove function calls early. Also, it helps to get better optimization results. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133993/new/ https://reviews.llvm.org/D133993 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
