add uwtable if unwind table is needed,regardless of nothrow/nothow status. Fulfill-f[no]-unwind-tables
Depends on reviews.llvm.org/D31139
Differential D31140
[LLVMbugs] [Bug 18710] Only generate .ARM.exidx and .ARM.extab when needed in EHABI chrib on Mar 20 2017, 10:42 AM. Authored by
Details
Diff Detail Event TimelineComment Actions 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. Comment Actions 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) And of course without exception runtime environment (the test here) we don't need this table. So I can see 3 cases:
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. Comment Actions Is it possible to enable cantunwind for one function and enable for another? If so, does this have to be a function attribute? Comment Actions Yes we can enable cantunwind with the nothrow gcc attribute when exceptions are enabled So the flag should work, but conceptually I agree, this semantic should be better carried thru attributes, hopefully without adding a new one Comment Actions If you want to follow what we do for x86-64 on ARM, you should be doing this in the driver, not codegen (grep for IsUnwindTablesDefault). Comment Actions Yes, I also tried to look into this direction, but I did not find a clean way from the driver to emit the attribute based on codegen options and language. Also unwind-tables must not be the default for arm. (for C this is what I want to eliminate). In fact I haven't found an example of setting attributes in the driver. not sure it's even possible. Also, setting this new uwtable attribute close to the existing NoUnwind attribute in CodeGen makes the orthogonality both attributes more obvious (or less obscure :-). This said, testing for the Triple Arch here is not clean (I probably prefer a target overloads) but that was a conservative approach. to avoid that we would need to propose a follow up that simplifies the code as: // We might need an unwind table, even if the function cannot throw. if (hasUnwindExceptions(LangOpts) || CodeGenOpts.UnwindTables) B.addAttribute(llvm::Attribute::UWTable); // If the module doesn't support exceptions the function cannot throw. // We can have a nothrow function even if unwind tables are required. if (!hasUnwindExceptions(LangOpts)) B.addAttribute(llvm::Attribute::NoUnwind); but this will impact all targets and can cause other changes in the backend, so it's probably better to do this separately. Do you have an advice on that ? thanks, Comment Actions forgot to give the motivating figure. this brings a code size reduction of 9.5 % (geomean of text sections sizes) on coremarkpro -Oz for cortex-m3 eabi Comment Actions Oh, you don't want to emit them by default. :) I'm not sure what you're trying to do here... there are three possibilities:
We don't really care whether "uwtable" is set in the first scenario; it's obvious we need the table anyway. So I'm not sure what you're trying to accomplish here. (This is why I suggested using needsUnwindTableEntry() on the LLVM patch.) Comment Actions Hello Eli, You were right, using IsUnwindTablesDefault is the correct way to abstract the need for UnwindTables. I missed the relationship between the driver munwind-table and GodeGenOpts.UnwindTables use in Codegen. Here is a new patch just setting IsUnwindTablesDefault for EHABI. No Changes in the testsuite results with D31139
Comment Actions OK, we can refine so that unwind-table is also not generated for C++ -fno-exceptions. To summarize this gives or C++ :
(1) without unwind, no handler can be found so the default is to terminate. for C :
Cheers, Comment Actions I would rather not make ARM baremetal do something different from every other target... On Linux, for most targets, we don't add the uwtable attribute by default; without the uwtable attribute, non-ARM backends (e.g. aarch64) only emit tables for functions which might unwind. Following this precedent is probably the most straightforward. MachO::IsUnwindTablesDefault does something similar to what you're doing here (except it doesn't depend on CCCIsCXX). But Apple platforms have to deal with ObjC exception handling, so I'm not sure that's the best precedent to follow. Comment Actions oops yes of course. I forgot some bits while switching from testing the arch to testing the platform. indeed --target=arm-none-linux-gnueabihf lost its unwind info in c++. Surprisingly not caught by the llvm tests, will add some. thanks Comment Actions Hello, I didn't find an easy way factorize the change in IsUnwindTableDefault to support the multiple ARM toolchains. After a quick check in Triple::arm in Driver/Toochains, many seem impacted (excepted NetBSD and Darwin that uses DwarfCFI or SJLG). So here is an attempt to move this into a small arm hook and use. Also, I realized that the cxx tests was not correctly checked because most of them are invoked as "clang" instead if "clang++" So another proposal is to check the input type in IsUnwindTablesDefault. Finally I've added the clang tests to check for this. thanks ! Comment Actions Changes since last revision:
Comment Actions Hello, I realized that testing CCCisCXX for IsUnwindTablesDefault was not really good and useless here, because we cannot treat C as C++ mode. In fact only the file type matters, as seen in the tests. So I'd like to amend my previous proposal to
sorry for the respin, thanks ! Comment Actions hello, realizing that this has been stuck for a while now. did I answer all the concerns ? rebased patch, gentle ping :-) many thanks, Christian Comment Actions damn it last diff was the llvm part (D31139). Here is the clang part. sorry for the noise, still not experienced with Phabricator. |
This still seems weird. In most situations, I would expect you want the same behavior for C code and C++ with -fno-exceptions. On other platforms, we get that behavior by just returning false (the default).