[llvm-dev] RFC: We need to explicitly state that some functions are reserved by LLVM

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Sat Nov 4 16:28:33 PDT 2017


> On Nov 4, 2017, at 3:12 PM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>> I think this is the pragmatic way forwards. For a concise example of
>> how broken/surprising the current behaviour is:
>> <snip>
>> ffloor is legal for AArch64, meaning frintm is produced rather than a
>> call to floor. Deleting the 'readnone' attribute from the floor
>> function will avoid lowering to ffloor. Compile with -mtriple=arm and
>> the generated assembly has completely different semantics (calling
>> floor and so aborting).
>> 
>> I'm not sure if there's a tracking bug for this, but the earliest
>> mention I could find with a quick search was
>> <https://bugs.llvm.org/show_bug.cgi?id=2141 <https://bugs.llvm.org/show_bug.cgi?id=2141>>.
> 
> As John Regehr clarified on Twitter - the potential issues when
> names+arguments clash with C99 standard library functions is
> documented in the LangRef, though it's (at the time of writing)
> stuffed awkwardly under the "Example" subheading for the call
> instruction <http://llvm.org/docs/LangRef.html#id306 <http://llvm.org/docs/LangRef.html#id306>>.
> 
> I suppose the point is: the issue described by Chandler in this RFC is
> a very strong motivation for changing _something_. The approach
> suggested by David would solve Chandler's bug, but also allow this
> function naming restriction to be lifted altogether which seems like
> an even bigger win.

I think that the right thing to do is to make the compiler ignore well-known functions that have internal linkage.  Treating a symbol with internal linkage as “known” is unsafe and incorrect even if it was derived from a well-known function, because IPO can transform it (e.g. by constant propagating values into the arguments).

If the use-case for statically linking in libc + internalizing it is important, then we need to find another solution to preserve those optimizations, it isn’t safe to just blindly assume an internal symbol with a well known name is the well known function..

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171104/b5a9c6fa/attachment-0001.html>


More information about the llvm-dev mailing list