[prev in list] [next in list] [prev in thread] [next in thread] 

List:       llvm-dev
Subject:    Re: [LLVMdev] [Bug 3756] __attribute__((always_inline)) and
From:       Pierre Habouzit <madcoder () debian ! org>
Date:       2009-03-15 19:36:51
Message-ID: 20090315193651.GC30970 () artemis ! corp
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla-daemon@cs.uiuc.edu wrote:
> http://llvm.org/bugs/show_bug.cgi?id=3756
> 
> Chris Lattner <clattner@apple.com> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |WONTFIX
>
> --- Comment #6 from Chris Lattner <clattner@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@debian.org
OOO                                                http://www.madism.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


[prev in list] [next in list] [prev in thread] [next in thread]