On Wed, Jun 20, 2012 at 8:21 AM, Daniel Santos <danielfsan...@att.net> wrote:
> Thanks for your response!
>
> On 06/19/2012 08:40 AM, Richard Guenther wrote:
>> On Tue, Jun 19, 2012 at 4:41 AM, Daniel Santos <danielfsan...@att.net> wrote:
>>> So before filing any feature request bugs, I figured I should bring my
>>> discussion here first, as I believe some enhancements to gcc can better
>>> enable this type of programming.
>> The question this boils down to is - what is a constant? The current
>> implementation is pretty clear (see builtins.c:fold_builtin_constant_p)
>> and excludes any addresses of entities (being functions or variables).
>> Which probably asks for a new builtin to verify this, not over-loading
>> __builtin_constant_p.
> To be honest, I haven't peeked at the gcc sources yet for fear I would
> want to get too involved! :) I'll look at this. And yes, it would
> certainly make sense to have a separate builtin for this.
>>
>>> First off, we need a mechanism to verify constness of a function pointer
>>> at build time and generate an error when the value is non-const, similar
>>> to the construct:
>>>
>>> #define BUILD_BUG_ON_NON_CONST(arg) \
>>> do { \
>>> extern void __value_non_constant(void) \
>>> __attribute__((error("value not constant"))); \
>>> if (!__builtin_constant_p(arg)) \
>>> __not_constant_error(); \
>>> } while (0)
>>>
>>> Second, it will be helpful to have a mechanism to generate a -Winline
>>> warning when a function call by pointer cannot be inlined. Obviously,
>>> this is impossible if you can't first determine that it's a const
>>> function pointer and resolve that to the actual function. I'm sorry to
>>> say that I don't have a suggestion for doing this other than some
>>> __builtin_isinlineable() type of function (that accepts a function
>>> pointer). Perhaps solving the above problem and assuring that, after
>>> this test for function pointer constness succeeds and the const function
>>> pointer can be resolved to an inline function, the compiler can just
>>> emit a warning as it would when a normal function call to an inline
>>> cannot be inlined. Here's an example:
>>>
>>> #include <stdio.h>
>>> static inline int myfunc(int a) {
>>> return a + 42;
>>> }
>>>
>>> static inline void jack(int (*const fnptr)(int)) {
>>> /* macro from above, except working for function pointers */
>>> BUILD_BUG_ON_NON_CONST(fnptr);
>>>
>>> /* if the above test passes, any inability to inline myfunc should
>>> * produce a -Winline warning
>>> */
>> I think that would be essentially the same as declaring myfunc
>> with attribute always-inline. You'd get an error if the function pointer
>> turns into a direct call and is not inlined.
> I haven't tried this yet, but I will. However, I thought that
> always_inline just caused the function to be inlined at all optimization
> levels (including none). If not, then it's incorrectly documented.
Yes, that's true. Though there are no guarantees for indirectly called
always-inline functions, thus at -O0 there may be practically no inlining
for your case.
Richard.
> Thanks,
> Daniel
