[Bug tree-optimization/114779] New: __builtin_constant_p does not work in inline functions

[Bug tree-optimization/114779] New: __builtin_constant_p does not work in inline functions

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

            Bug ID: 114779
           Summary: __builtin_constant_p does not work in inline functions
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Take the following C test case with a special function register (SFR)
definition at a constant address:

#define SFR (*(volatile int*) 0x100)

static __inline__ __attribute__((__always_inline__))
void test_bcp (int volatile *psfr)
{
    if (! __builtin_constant_p (psfr))
        __asm (".error \"psfr is not constant\"");
}

int main (void)
{
    test_bcp (& SFR);
    return 0;
}

Then compile with:

$ gcc bar.c -c -O2
Assembler messages:
Error: psfr is not constant

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That has nothing to do with inline functions and everything to do with pointer
arguments to __builtin_constant_p.  The builtin behaved that way since at least
1998.
The current version still has
  /* If this expression has side effects, show we don't know it to be a
     constant.  Likewise if it's a pointer or aggregate type since in
     those case we only want literals, since those are only optimized
     when generating RTL, not later.
     And finally, if we are compiling an initializer, not code, we
     need to return a definite result now; there's not going to be any
     more optimization done.  */
  if (TREE_SIDE_EFFECTS (arg)
      || AGGREGATE_TYPE_P (TREE_TYPE (arg))
      || POINTER_TYPE_P (TREE_TYPE (arg))
      || cfun == 0
      || folding_initializer
      || force_folding_builtin_constant_p)
    return integer_zero_node;
What triggers here is the POINTER_TYPE_P (TREE_TYPE (arg)) case.  So, the
builtin is immediately folded into 0 in that case.

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

--- Comment #2 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Notice that when &SFR is used directly in __builtin_constant_p without an
inline function, then the code works as expected:

int main (void)
{
    if (__builtin_constant_p (& SFR))
        __asm (".warning \"psfr = %0 is constant\"" :: "n" (& SFR));
    return 0;
}

$ gcc bar.c -c -O2
Assembler messages:
Warning: psfr = $256 is constant

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But in that case the POINTER_TYPE_P case doesn't trigger, because it is
INTEGER_CST and
so
  /* If we know this is a constant, emit the constant of one.  */
  if (CONSTANT_CLASS_P (arg)
      || (TREE_CODE (arg) == CONSTRUCTOR
          && TREE_CONSTANT (arg)))
    return integer_one_node;
triggers first.
There is another case where the builtin can return true for a pointer, and that
is
when it is called with a string literal (__builtin_constant_p ("abcd")):
  if (TREE_CODE (arg) == ADDR_EXPR)
    {
       tree op = TREE_OPERAND (arg, 0);           
       if (TREE_CODE (op) == STRING_CST
           || (TREE_CODE (op) == ARRAY_REF
               && integer_zerop (TREE_OPERAND (op, 1))
               && TREE_CODE (TREE_OPERAND (op, 0)) == STRING_CST))
         return integer_one_node;
    }
But if you use even in the same function
  int volatile *psfr = SFR;
  __builtin_constant_p (psfr)
it will fold to 0.

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

--- Comment #4 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
As far as I understand, & SFR has no side effects.

But when it is used as argument to an (inline) function, then it does have side
effects?

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It isn't about side-effects.  It is about it having pointer type.
If you change your testcase to
    uintptr_t psfr_int = (uintptr_t) psfr;
    if (! __builtin_constant_p (psfr_int))
       ....
then it will work.
__builtin_constant_p ((uintptr_t) psfr) will not work though, because the
folding strips casts and the POINTER_TYPE_P case triggers in that case as well.
I am not sure it would be a good idea to change the __builtin_constant_p
behavior at this point, a lot of code in the wild might depend on its current
behavior.

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Recognizing more __builtin_constant_p situations is a good thing, IMO.

It would allow to transition from macros to inline functions in such
situations, for example in inline asm that has extra opcodes for const
addresses.

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Note that the test about side-effects also makes it impossible to test for
constantness of values passed to function by reference which could be also
useful. Workaround is to load it into temporary so the side-effect is not seen.
So that early folding to 0 never made too much of sense to me.

I agree that it is a can of worms and it is not clear if changing behaviour
would break things...

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I tried removing the TREE_SIDE_EFFECTS check at some point and it had quite
some fallout even in the testsuite.  Don't remember the PR I tried this for ...

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

--- Comment #9 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
When this PR won't be fixed, then maybe at least the documentation could
clarify how to port macros to inline functions.

[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation

--- Comment #10 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
so I set keyword "documentation"