[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic