[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 13:58:47 PDT 2017


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:

This IR:

"""
define double @floor(double %a) nounwind readnone {
  call void @abort()
  unreachable
}

define double @foo(float %a) nounwind {
  %1 = fpext float %a to double
  %2 = call double @floor(double %1)
  ret double %2
}

declare void @abort()
"""

Results in the following SelectionDAG:

"""
Initial selection DAG: BB#0 'foo:'
SelectionDAG has 8 nodes:
  t0: ch = EntryToken
        t2: f32,ch = CopyFromReg t0, Register:f32 %vreg0
      t3: f64 = fp_extend t2
    t4: f64 = ffloor t3
  t6: ch,glue = CopyToReg t0, Register:f64 %D0, t4
  t7: ch = AArch64ISD::RET_FLAG t6, Register:f64 %D0, t6:1
"""

And the following machine code:

"""
    .globl    foo                     // -- Begin function foo
    .p2align    2
    .type    foo, at function
foo:                                    // @foo
// BB#0:
    fcvt    d0, s0
    frintm    d0, d0
    ret
.Lfunc_end1:
    .size    foo, .Lfunc_end1-foo
                                        // -- End function
"""

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

Best,

Alex


More information about the llvm-dev mailing list