On 11/24/2016 12:24 AM, Senthil Kumar Selvaraj wrote:

Jeff Law writes:

On 11/23/2016 02:54 AM, Senthil Kumar Selvaraj wrote:
Hi,

  The below patch fixes uninit-19.c for avr by adding
  -finline-small-functions for avr.

  The test fails for avr because fn1 does not get inlined into fn2. Inlining
  occurs for x86_64 because fn1's computed size equals call_stmt_size. For
  avr, 32 bit memory moves are more expensive, and b[3] = p10[a] results in
  a bigger size for fn1, resulting in estimate_growth > 0 and no inlining.

  Adding -finline-small-functions forces early inliner to inline fn1,
  making the test pass.

  Committed to trunk.

Regards
Senthil

gcc/testsuite/ChangeLog

2016-11-23  Senthil Kumar Selvaraj  <senthil_kumar.selva...@atmel.com>

        * gcc.dg/uninit-19.c: Add -finline-small-functions for avr.
How about instead forcing inlining via the always_inline attribute?  If
inlining is indeed expected and necessary, that seems better than
-finline-small-functions.

I considered it, but a previous discussion in the mailing list backed
off from a similar proposal
(https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00517.html), and I wasn't
sure if always_inline would break the pic/non-pic distinction somehow.

Should I revert this and mark the function always_inline/static?
It's often not obvious what the right thing to do is. I think it'll ultimately come down to trying to make an educated guess what the test is really trying to do and whether or not it it inherently depends on inlining.

Your call whether to go back and use the always_inline attribute on that particular test.

Jeff

Reply via email to