| Message ID | 87fvnx4z57.fsf@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 02/05/14 03:44, Nick Clifton wrote: > Hi Jeff, Hi Alex, > > Sorry - another MN10300 patch - this time for the stack size reported > with -fstack-usage. Currently the value includes the stack frame, but > it does not take into account any registers that might have been > pushed onto the stack. > > The patch below fixes this problem, but there is one thing that I am > not sure about - is it OK to use __builtin_popcount() or should I be > calling some other function ? According to our coding conventions, the ability to build with something other than gcc is still desirable. You could argue that you're unlikely to be bootstrapping on a mn103 with something other than GCC and if you're building a cross, you could start by first building gcc native. However, it's pretty easy to avoid the headaches and just provide a popcount routine. I don't think this code is at all performance critical (once per function being compiled), so a simple popcount should be sufficient. No need for lookup tables IMHO. jeff
On Wed, 5 Feb 2014, Jeff Law wrote: > However, it's pretty easy to avoid the headaches and just provide a popcount > routine. I don't think this code is at all performance critical (once per > function being compiled), so a simple popcount should be sufficient. No need > for lookup tables IMHO. hwint.[ch] provide popcount_hwi, if HOST_WIDE_INT is a suitable type. (Personally I think there are lots of bits of standard integer manipulation functionality, such as popcount, that are common in processor instructions and compiler intrinsics, but could do with having bindings in ISO C to provide a standard way to access that functionality. Such bindings might take the form of library functions / macros that compilers / library headers can then optimize as appropriate; that seems most in the ISO C style rather than __builtin_*. Even outside of ISO C, I suspect there's quite a bit in common between target-specific builtins for different targets where a target-independent builtin would be better - and for that matter, target-specific builtins where some form of standard binding already exists but isn't supported in GCC, or where the target-specific builtin duplicates something generic in GNU C.)
On 02/05/14 11:26, Joseph S. Myers wrote: > On Wed, 5 Feb 2014, Jeff Law wrote: > >> However, it's pretty easy to avoid the headaches and just provide a popcount >> routine. I don't think this code is at all performance critical (once per >> function being compiled), so a simple popcount should be sufficient. No need >> for lookup tables IMHO. > > hwint.[ch] provide popcount_hwi, if HOST_WIDE_INT is a suitable type. Even better. > > (Personally I think there are lots of bits of standard integer > manipulation functionality, such as popcount, that are common in processor > instructions and compiler intrinsics, but could do with having bindings in > ISO C to provide a standard way to access that functionality. Agreed. Jeff
Index: gcc/config/mn10300/mn10300.c =================================================================== --- gcc/config/mn10300/mn10300.c (revision 207498) +++ gcc/config/mn10300/mn10300.c (working copy) @@ -745,13 +745,15 @@ mn10300_expand_prologue (void) { HOST_WIDE_INT size = mn10300_frame_size (); + int mask; + mask = mn10300_get_live_callee_saved_regs (NULL); + /* If we use any of the callee-saved registers, save them now. */ + mn10300_gen_multiple_store (mask); + if (flag_stack_usage_info) - current_function_static_stack_size = size; + current_function_static_stack_size = size + __builtin_popcount (mask) * 4; - /* If we use any of the callee-saved registers, save them now. */ - mn10300_gen_multiple_store (mn10300_get_live_callee_saved_regs (NULL)); - if (TARGET_AM33_2 && fp_regs_to_save ()) { int num_regs_to_save = fp_regs_to_save (), i; @@ -767,6 +769,9 @@ unsigned int strategy_size = (unsigned)-1, this_strategy_size; rtx reg; + if (flag_stack_usage_info) + current_function_static_stack_size += num_regs_to_save * 4; + /* We have several different strategies to save FP registers. We can store them using SP offsets, which is beneficial if there are just a few registers to save, or we can use `a0' in