<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On May 20, 2013, at 8:59 PM, Bob Wilson <<a href="mailto:bob.wilson@apple.com">bob.wilson@apple.com</a>> wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div>On May 20, 2013, at 11:11 AM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:</div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">A builtin attribute seems to make sense, I've always had this faint<br>unease at the "assume all functions with this name are magic" aspect<br>of the libcall optimizers. Though it is unfortunate that the same<br>functions have different meanings in arc and non-arc mode.</div></blockquote><br></div><div>Are you suggesting that we completely drop the nobuiltin attribute and switch to a scheme where nothing is assumed to be a builtin unless it has that attribute?</div></div></blockquote></div><br><div>That seems like the right fix to me. I can't think of any analogous source-language or environmental assumptions that LLVM unconditionally makes without an attribute or metadata there to bless it — well, except for compiler runtime functions like memcpy, soft-float functions, etc.</div><div><br></div><div>John.</div></body></html>