rL373738 hits assertion in lib/Target/ARM/ARMFrameLowering.cpp:468

[Quuxplusone]

Bugzilla Link	PR44231
Status	NEW
Importance	P enhancement
Reported by	Alina Sbirlea (alina.sbirlea@gmail.com)
Reported on	2019-12-05 16:27:07 -0800
Last modified on	2019-12-06 15:28:45 -0800
Version	trunk
Hardware	PC All
CC	chandlerc@gmail.com, llvm-bugs@lists.llvm.org, smithp352@googlemail.com, srj@google.com, t.p.northover@gmail.com, Ties.Stuij@arm.com, tim.northover@arm.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

assert.h assertion failed at llvm/lib/Target/ARM/ARMFrameLowering.cpp:468 in
virtual void llvm::ARMFrameLowering::emitPrologue(llvm::MachineFunction &,
llvm::MachineBasicBlock &) const: getMaxFPOffset(MF.getFunction(), *AFI) <=
FPOffset && "Max FP estimation is wrong"

To reproduce:
../bin/llc -O3 --mtriple=arm-apple-ios --mcpu=cortex-a9 --mattr=+neon test.ll

On:

target datalayout = "e-m:o-p:32:32-Fi8-f64:32:64-v64:32:64-v128:32:128-a:0:32-
n32-S32"
target triple = "arm-apple-ios"

%buffer_t = type { i64, i32 }
%closure_t = type { i32 }
declare float @llvm.floor.f32(float)
declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i1 immarg)
declare void @llvm.trap()

define void @func(%buffer_t* noalias %input.buffer, float %scale_factor)
local_unnamed_addr {
entry:
  %t0 = alloca %closure_t, align 4
  %dimensions.i = getelementptr inbounds %buffer_t, %buffer_t* %input.buffer, i32 0, i32 1
  %t1 = icmp slt i32 undef, 32
  %y.i98 = call float @llvm.floor.f32(float undef)
  %b20 = fptosi float %y.i98 to i32
  %t2 = fdiv reassoc nnan ninf nsz contract afn float 0.000000e+00, %scale_factor
  %t3 = fadd reassoc nnan ninf nsz contract afn float %t2, -5.000000e-01
  %y.i99 = call float @llvm.floor.f32(float %t3)
  %b23 = fptosi float %y.i99 to i32
  %a17 = select i1 false, i32 %b20, i32 undef
  %t4 = select i1 false, i32 %a17, i32 undef
  %a22 = add nsw i32 %b23, 2
  %t5 = select i1 false, i32 %a22, i32 undef
  %a21 = add nsw i32 %t5, -1
  %a20 = select i1 undef, i32 %b23, i32 %a21
  %t6 = select i1 false, i32 %a20, i32 undef
  %input.min.0.required = select i1 %t1, i32 %t4, i32 %t6
  %t7 = bitcast %buffer_t* %input.buffer to i8*
  call void @llvm.memset.p0i8.i64(i8* nonnull align 8 dereferenceable(16) %t7, i8 0, i64 16, i1 false)
  store i32 2, i32* %dimensions.i, align 4
  %.sroa.0.0..sroa_cast = bitcast i8* undef to i32*
  store i32 %input.min.0.required, i32* %.sroa.0.0..sroa_cast, align 4
  call void @llvm.trap()
  unreachable
}

[Quuxplusone]

I had to revert https://reviews.llvm.org/rGa7d90af1be48234ce583e00fb16e33633d44ae38 as the crashes were blocking the respective teams.

[Quuxplusone]

Five minutes after discovery, for a team relying directly on ToT LLVM behaviour? A bit premature IMO, but what's done is done.

[Quuxplusone]

(In reply to Tim Northover from comment #2)
> Five minutes after discovery, for a team relying directly on ToT LLVM
> behaviour? A bit premature IMO, but what's done is done.

Just to be clear, while the revision got a comment just before the revert, the
bug was filed yesterday.

And again, LLVM's policy has always been to revert-to-green. I think it is
really important that we stick to that, even when inconvenient. It is what lets
us and many other teams work on LLVM's ToT and find these kinds of bugs sooner
rather than later.