[LLVMdev] [Bug 3756] __attribute__((always_inline)) and __builtin_constant_p

[Pierre Habouzit]

[ please CC: me as I'm not subscribed ]

On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla-daemon at cs.uiuc.edu wrote:
> http://llvm.org/bugs/show_bug.cgi?id=3756
> 
> Chris Lattner <clattner at apple.com> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |WONTFIX
>
> --- Comment #6 from Chris Lattner <clattner at apple.com>  2009-03-10 23:13:33 ---
> Unfortunately, this will never be fixed in either llvm-gcc or clang. 
> __builtin_constant_p is a "best effort" constant folding tester, which is
> allowed to fail.  You should never write code that assumes that
> __builtin_constant_p can't fail (if you need that, just don't use
> __builtin_constant_p).


> It would be interesting and useful to bring this up on the glibc list
> to see if they are willing to fix their headers.

Hahahaha, you never talked to Uli before did you ?

> Barring that, if this is really important to you, please raise the issue on the
> llvmdev list.  We will need IR extensions to support this among other things.

Well, I don't expect __builtin_constant_p to works always. That's not
precisely the issue. I expect though __attribute__((always_inline))
functions to be expanded prior to any optimization pass, because it's
what it means. Those functions are basically type-safe macros.

If you do that, then my problem go away at once. For what it's worth, my
always_inline functions are always functions that allow constant-folding
of its result when parameters are known at compile time, or fallbacks to
a real, non inlined, implementation else. Typical (silly but useful for
my point) use is for example, a function that is:

extern int __utf8_charlen(wchar_t c);
__attribute__((always_inline))
static inline int utf8_charlen(wchar_t c) {
    if (__builtin_constant_p(c)) {
        if (c < 0 || c >= 0x200000)
	    return 0;
        return 1 + (c >= 0x80) + (c >= 0x800) + (c >= 0x10000);
    }
    return __utf8_charlen(c);
}

I really expect that here, if I have a straight utf8_charlen('\0') call,
llvm-gcc would first expand utf8_charlen inline, and then, optimizes the
__builtin_constant_p away. I mean, the cases where llvm-gcc is unable to
do the optimizations I somehow expect it to do, the arguments are always
direct constants passed to it, not through any kind of local variable,
hence a best-effort algorithm should just work.

-- 
·O·  Pierre Habouzit
··O                                                madcoder at debian.org
OOO                                                http://www.madism.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090315/e128078c/attachment.sig>