From llvm-dev Sun Mar 15 19:36:51 2009 From: Pierre Habouzit Date: Sun, 15 Mar 2009 19:36:51 +0000 To: llvm-dev Subject: Re: [LLVMdev] [Bug 3756] __attribute__((always_inline)) and Message-Id: <20090315193651.GC30970 () artemis ! corp> X-MARC-Message: https://marc.info/?l=llvm-dev&m=123716433713992 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0242625896==" --===============0242625896== Content-Type: multipart/signed; boundary="0lnxQi9hkpPO77W3"; protocol="application/pgp-signature"; micalg=SHA1 Content-Disposition: inline --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ 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=3D3756 >=20 > Chris Lattner changed: > > What |Removed |Added > -------------------------------------------------------------------------= --- > Status|NEW |RESOLVED > Resolution| |WONTFIX > > --- Comment #6 from Chris Lattner 2009-03-10 23:13:= 33 --- > Unfortunately, this will never be fixed in either llvm-gcc or clang.=20 > __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 thi= ngs. 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 >=3D 0x200000) return 0; return 1 + (c >=3D 0x80) + (c >=3D 0x800) + (c >=3D 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. --=20 =C2=B7O=C2=B7 Pierre Habouzit =C2=B7=C2=B7O madcoder@debia= n.org OOO http://www.madism.org --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkm9WNMACgkQvGr7W6HudhxySQCfXLDU0ighJNlZWjmq/JNVuraq J5UAn1k0KIUe5b5n3SjsSAIqRo8ns0+M =8jQ3 -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- --===============0242625896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ LLVM Developers mailing list LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev --===============0242625896==--