[PATCH] D67216: [cfi] Add flag to always generate call frame information
JohnReagan added a comment. Does the current code generate all the prologue cfi directives? Epilogue too? The last time I checked, it did not (especially for epilogues). Fully asynch prologue/epilogue is one of the things that we need for OpenVMS and will be doing that work. We're also looking at using the compact format instead of the CFI form (at least for routine bodies). clang's driver already recognizes "-fasynchronous-unwind-tables" today and maps that to "-munwind-tables" and probably should be switched to setting your new "always-need-cfi" or simply change your name.Either way, I think there is an interaction between them. From the code in Clang.cpp // This is a coarse approximation of what llvm-gcc actually does, both // -fasynchronous-unwind-tables and -fnon-call-exceptions interact in more // complicated ways. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67216/new/ https://reviews.llvm.org/D67216 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D86310: [X86] Align i128 to 16 bytes in x86-64 datalayout
JohnReagan added a comment. As a legacy OS provider on a platform that needs/requires ABI compatibility, I don't like the direction this is going. Like @rnk, I would having MORE control over struct layout is better than less. I'm adapting non-traditional languages to LLVM which allow very explicit control over layout of fields in structs. I have system-provided headers and data structures that have been the same since 1977. Fortunately, none contain i128 (or f128) sized items but I'm watching closely about any undermining of data layout control. This area of layout control (both with fields in structures and variables in sections) has been our biggest challenge with getting OpenVMS running on x86 using LLVM. I really don't want to be locked into a older version of the backend out of concerns about ABI reshuffling. We guarantee that previously compiled images continue to execute forever and that you can mix/match objects across versions. You can compile one file today and link it against an object library (provided by a 3rd party vendor) that was compiled 5 years ago with older compilers and it will work as intended. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86310/new/ https://reviews.llvm.org/D86310 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D115441: [X86][MS] Add 80bit long double support for Windows
JohnReagan added a comment. Does any of this impact the -f128 support? We use f128 x-float on OpenVMS. We've historically only aligned on 8-byte boundaries for legacy reasons (I'm not opposed to having my own mods to control the record layout and/or data layout) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D115441/new/ https://reviews.llvm.org/D115441 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
