This is an archive of the discontinued LLVM Phabricator instance.

[libunwind][ARM] Improve unwinder stack usage - Make WMMX support optional
ClosedPublic

Authored by rmaprath on Jul 5 2016, 5:44 AM.

Details

Summary

These registers are only available on a limited set of ARM targets (those based on XScale). Other targets should not have to pay the cost of these.

This patch shaves off about ~300 bytes of stack usage and ~1KB of code-size.

Diff Detail

Repository
rL LLVM

Event Timeline

rmaprath updated this revision to Diff 62739.Jul 5 2016, 5:44 AM
rmaprath retitled this revision from to [libunwind][ARM] Improve unwinder stack usage - Make WMMX support optional.
rmaprath updated this object.
rmaprath added reviewers: jroelofs, bcraig.
rmaprath added a subscriber: cfe-commits.
bcraig added inline comments.Jul 5 2016, 8:43 AM
CMakeLists.txt
108 ↗(On Diff #62739)

Buried in one of the .s files, I see a preprocessor definition check for __ARM_WMMX. Can the use of the preprocessor define be used instead of adding a new configuration option?

rmaprath added inline comments.Jul 5 2016, 9:13 AM
CMakeLists.txt
108 ↗(On Diff #62739)

Missed that. Digging into some past commits bumped into http://reviews.llvm.org/D5314#74501

I think it's safe to guard the whole thing with __ARM_WMMX. Will do that instead.

rmaprath added inline comments.Jul 5 2016, 9:40 AM
CMakeLists.txt
108 ↗(On Diff #62739)

Although, now I'm not sure if clang ever generates this predefine.

The ACLE clearly says it should be defined for supporting targets: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf

I'm not sure if that justifies using this predefine to completely exclude all of WMMX support. Perhaps a build option is safer? @jroelofs: what's your take?

I don't think that clang nor LLVM have much in terms of support for XScale. Can we do something more convoluted perhaps? I like the preprocessor based approach. However, if the compiler doesn't define it with the correct target, we define it and push it into the CPPFLAGS. This way, in the future, we can rely on the compiler to do the right thing and eventually lose the cmake magic.

I don't think that clang nor LLVM have much in terms of support for XScale. Can we do something more convoluted perhaps? I like the preprocessor based approach. However, if the compiler doesn't define it with the correct target, we define it and push it into the CPPFLAGS. This way, in the future, we can rely on the compiler to do the right thing and eventually lose the cmake magic.

Sounds good to me.

Just to confirm, we keep the cmake option and make it define __ARM_WMMX instead of _LIBUNWIND_ARM_WMMX? Or did you mean we try to figure it out based on the target? I think the latter would be very complicated; WMMX is not an architectural feature but an extension supported on some processors (like the PXA series: http://www.marvell.com/application-processors/pxa-family/).

WDYT?

Thanks.

/ Asiri

Right, we make it a cmake define corresponding to the AEABI name. In the future when clang knows to correctly emit the macro, we just rely on that. Figuring it out based on the target in my case means: ${CMAKE_C_COMPILER} -x c -E - -dM <<< "__ARM_WMMX". Thats not too terrible to do, but since the support for WMMX is rare, I think skimping on that bit of preparation is acceptable too.

rmaprath updated this revision to Diff 62890.Jul 6 2016, 9:44 AM
rmaprath added a reviewer: compnerd.
rmaprath removed a subscriber: compnerd.
  • Use __ARM_WMMX instead of _LIBUNWIND_ARM_WMMX
  • Add a comment to the cmake option LIBUNWIND_ENABLE_ARM_WMMX to explain why it is done this way
compnerd accepted this revision.Jul 6 2016, 8:16 PM
compnerd edited edge metadata.
compnerd added inline comments.
src/Registers.hpp
1497 ↗(On Diff #62890)

Early returns would be nicer imo.

1706 ↗(On Diff #62890)

Early returns would be nicer here as well imo.

This revision is now accepted and ready to land.Jul 6 2016, 8:16 PM
rmaprath added inline comments.Jul 7 2016, 1:28 AM
src/Registers.hpp
1497 ↗(On Diff #62890)

Not sure if I follow, did you mean to check the bounds of regNum the first thing and _LIBUNWIND_ABORT sooner than later? Might convolute the code given the conditional on __ARM_WMMX and I'm not sure what benefit it brings? Or perhaps I misunderstood you?

I'll commit the current patch as it is for the moment and then do a clean-up (once I understand what you mean).

Thanks.

This revision was automatically updated to reflect the committed changes.
compnerd added inline comments.Jul 7 2016, 5:51 PM
src/Registers.hpp
1497 ↗(On Diff #62890)

Oh, that was meant, as, we can write the code a slight bit nicer, which is beyond the scope of your change. If you don't mind doing a bit more clean up -- a follow up patch to improve this would be appreciated!

Basically, we have a number of if/else if cases with a unreachable. We should replace this with a series of

if (<condition>) {
  <operation>
  return;
}
rmaprath added inline comments.Jul 12 2016, 1:12 AM
src/Registers.hpp
1497 ↗(On Diff #62890)