Re: [PATCH] D31140: [LLVMbugs] [Bug 18710] Only generate .ARM.exidx and .ARM.extab when needed in EHABI
Hi Jon Le 03/21/2017 à 09:11 PM, Jonathan Roelofs a écrit : On 3/21/17 1:53 PM, Christian Bruel via Phabricator wrote: chrib added a comment. In https://reviews.llvm.org/D31140#706411, @jroelofs wrote: Can you clarify the logic here? It's my understanding that: `-fno-exceptions` does *not* imply `-fno-unwind-tables` however: `-fno-unwind-tables` *does* imply that exceptions cannot be used on targets that require the tables to do unwinding. Yes, (bad things might happen or (std::terminate will be called, or destructors not called.)... But -f[no]-unwind-tables implies the UWTable attribute, not NoUwind attribute. To toggle NoUnwind, use -fno-exceptions And this is getting worse with .canunwind which means DoesNotThrow :) in my understanding, the logic is as follow: Since "An exception cannot propagate through a function with a nounwind table. The exception handling runtime environment terminates the program if it encounters a nounwind table during exception processing." (ARM Information Center) The "nounwind" LLVM attribute, which means "Function does not throw" translates as the EXIDX_CANTUNWIND value in the exception table index table which needs to be created for the purpose (for the function) I think the problem is here, actually. "nounwind" implies "does not throw", but "does not throw" really should not imply "nounwind". This is something that ought to be clarified in the langref with the addition of a "does not throw" attribute. Then the optimizer should be fixed to deduce "does not throw" instead of "nounwind", and we can let "nounwind" continue to imply .cantunwind. Absolutely, renaming the nounwind attribute into a nothrow would make things lot clearer! That would fix the semantic (which is already a lot). This has been already discussed here and there. e.g for reference this thread http://lists.llvm.org/pipermail/llvm-dev/2014-February/070366.html without any outcome, because the optimizer cannot deduce, without a context information from clang, if the environment supports EH or not. One could imaging a global (LTO) analysis to find any cxa_throw in the IRs, but that would not pass the pre-compiled object barrier or dynamic dependencies. So this context information could be well derived either from the language (! C) or the fno-exception flag. Unfortunately none of them is known to the optimizer. The proposal was to make this information of the form of an option (like here) or eventually an additional attribute of the form nocantunwind (or noeh, any suggestion welcome). So attributes #0 = { nounwind nocantunwind} means for the arm streamer dont' emit the .cantunwind directive required by the EHABI if the function cant take exceptions And of course without exception runtime environment (the test here) we don't need this table. So I can see 3 cases: - nounwind set :Generate .cantunwind directive and unwind table - nounwind set but not EH Do not generate the .cantunwind directive and do not emit the unwind table - uwtable set Need to generate the unwind table (even without EH) The disable-arm-cantunwind flag means: without EH support if the function does not throw, do dot generate the exception tables and the EXIDX_CANTUNWIND value. I'm not a big fan of this workaround flag. I'd rather see this fixed by clarifying/fixing the semantics of the IR. yes we can clarify the semantic of the IR. But that will not be enough to fix the problem. nounwind implies emit .cantunwind which implies exception table nounwind + NOEH implies don't emit the exception table and we need this NOEH from clang. Now the question is how? 1) a new arm specific flag 2) a target independant no-exception flag 3) a nocantunwind attribute But I'm not a big fan of adding a new attribute for a arm specific need... Best Regards Christian Jon https://reviews.llvm.org/D31140 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D31140: [LLVMbugs] [Bug 18710] Only generate .ARM.exidx and .ARM.extab when needed in EHABI
Just to add to our comments bellow, One experiment I did is to use the nounwind/uwtable combination to achieve what we need. e.g: nounwind= emit nothing nounwind uwtable = emit the .exidx .extab section with the CANTUNWIND However I gave that up because of tests legacy. e.g ./CodeGen/ARM/ehabi.ll we test : ; (6) .cantunwind directive should be available if the function is marked with ; nounwind function attribute. So many tests would need to be rewritten as ; (6) .cantunwind directive should be available if the function is marked with ; nounwind uwtable function attributes So I'm not sure in which extend we can change attribute semantic if this implies adapting the regressions tests ? But if this is acceptable I'm ready to try this... any other opinion ? Cheers Christian Le 03/21/2017 à 09:11 PM, Jonathan Roelofs a écrit : On 3/21/17 1:53 PM, Christian Bruel via Phabricator wrote: chrib added a comment. In https://reviews.llvm.org/D31140#706411, @jroelofs wrote: Can you clarify the logic here? It's my understanding that: `-fno-exceptions` does *not* imply `-fno-unwind-tables` however: `-fno-unwind-tables` *does* imply that exceptions cannot be used on targets that require the tables to do unwinding. Yes, (bad things might happen or (std::terminate will be called, or destructors not called.)... But -f[no]-unwind-tables implies the UWTable attribute, not NoUwind attribute. To toggle NoUnwind, use -fno-exceptions And this is getting worse with .canunwind which means DoesNotThrow :) in my understanding, the logic is as follow: Since "An exception cannot propagate through a function with a nounwind table. The exception handling runtime environment terminates the program if it encounters a nounwind table during exception processing." (ARM Information Center) The "nounwind" LLVM attribute, which means "Function does not throw" translates as the EXIDX_CANTUNWIND value in the exception table index table which needs to be created for the purpose (for the function) I think the problem is here, actually. "nounwind" implies "does not throw", but "does not throw" really should not imply "nounwind". This is something that ought to be clarified in the langref with the addition of a "does not throw" attribute. Then the optimizer should be fixed to deduce "does not throw" instead of "nounwind", and we can let "nounwind" continue to imply .cantunwind. And of course without exception runtime environment (the test here) we don't need this table. So I can see 3 cases: - nounwind set :Generate .cantunwind directive and unwind table - nounwind set but not EH Do not generate the .cantunwind directive and do not emit the unwind table - uwtable set Need to generate the unwind table (even without EH) The disable-arm-cantunwind flag means: without EH support if the function does not throw, do dot generate the exception tables and the EXIDX_CANTUNWIND value. I'm not a big fan of this workaround flag. I'd rather see this fixed by clarifying/fixing the semantics of the IR. Jon https://reviews.llvm.org/D31140 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D31140: [LLVMbugs] [Bug 18710] Only generate .ARM.exidx and .ARM.extab when needed in EHABI
On 3/21/17 1:53 PM, Christian Bruel via Phabricator wrote: chrib added a comment. In https://reviews.llvm.org/D31140#706411, @jroelofs wrote: Can you clarify the logic here? It's my understanding that: `-fno-exceptions` does *not* imply `-fno-unwind-tables` however: `-fno-unwind-tables` *does* imply that exceptions cannot be used on targets that require the tables to do unwinding. Yes, (bad things might happen or (std::terminate will be called, or destructors not called.)... But -f[no]-unwind-tables implies the UWTable attribute, not NoUwind attribute. To toggle NoUnwind, use -fno-exceptions And this is getting worse with .canunwind which means DoesNotThrow :) in my understanding, the logic is as follow: Since "An exception cannot propagate through a function with a nounwind table. The exception handling runtime environment terminates the program if it encounters a nounwind table during exception processing." (ARM Information Center) The "nounwind" LLVM attribute, which means "Function does not throw" translates as the EXIDX_CANTUNWIND value in the exception table index table which needs to be created for the purpose (for the function) I think the problem is here, actually. "nounwind" implies "does not throw", but "does not throw" really should not imply "nounwind". This is something that ought to be clarified in the langref with the addition of a "does not throw" attribute. Then the optimizer should be fixed to deduce "does not throw" instead of "nounwind", and we can let "nounwind" continue to imply .cantunwind. And of course without exception runtime environment (the test here) we don't need this table. So I can see 3 cases: - nounwind set :Generate .cantunwind directive and unwind table - nounwind set but not EH Do not generate the .cantunwind directive and do not emit the unwind table - uwtable set Need to generate the unwind table (even without EH) The disable-arm-cantunwind flag means: without EH support if the function does not throw, do dot generate the exception tables and the EXIDX_CANTUNWIND value. I'm not a big fan of this workaround flag. I'd rather see this fixed by clarifying/fixing the semantics of the IR. Jon https://reviews.llvm.org/D31140 -- Jon Roelofs jonat...@codesourcery.com CodeSourcery / Mentor Embedded ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits