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

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Sat Nov 4 15:12:43 PDT 2017

On 4 November 2017 at 20:58, Alex Bradbury <asb at asbradbury.org> wrote:
> On 27 October 2017 at 19:31, Hal Finkel via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> I agree. Marking external functions from system headers seems like a
>> reasonable heuristic. We'd need some heuristic because it's not reasonable
>> for the frontend to know about every function the optimizer knows about.
>> Over-marking seems okay, however.
> 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>.

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>.

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.



More information about the llvm-dev mailing list