Re: pragma GCC optimize prevents inlining

[David Brown <david@westcontrol.com>]

On 04/01/2024 10:01, Hashan Gayasri via Gcc-help wrote:
> Hi,
> 
> I noticed that GCC doesn't inline functions that have extra optimization
> options added via pragma GCC optimize after the pop_options statement.
> 
> If the optimizations are different between the caller and the callee, seems
> like gcc behaves as if the called function's definition is opaque and not
> visible at all (as if it was declared in a different translation unit). It
> doesn't even notice that the function doesn't have side effects unless
> marked so explicitly.
> 
> I wanted the following to be to be optimized:
> 
> #pragma GCC push_options
> #pragma GCC optimize ("-ffast-math")
> 
> inline int64_t __attribute__ ((const)) RoundToNearestLong (double v)
> {
>      assert(fegetround() == FE_TONEAREST);
>      return std::lrint(v);
> }
> 
> #pragma GCC pop_options
> 
> 
> So that std::lrint uses the vcvtsd2si instruction on X86 with SSE2.  It
> does that but prevents the instruction from being inlined. I complied with
> - O3 -march=native -DNDEBUG.
> 
> If I used attribute always_inline, the inlined version didn't seem to
> respect the additional optimization options I provided.
> const and pure function attributes helped in removing unused/no side effect
> code paths but the function still got called.
> 
> 
> Please advice if there's any way work around for this. Using intrinsics
> works but less than ideal.
> 
> (Also let me know if I should be sending this to a different mailing list)
> 
> Thanks in advance!
> 
> Best Regards,
> Hashan Gayasri
> 

This is a general limitation in GCC, as far as I know.  I have come 
across it myself (in my case it was the "-fwrapv" flag).  As far as I 
remember from a previous discussion long ago, there is no easy workaround.