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

[Alex Bradbury via llvm-dev]

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.

Best,

Alex