This is an archive of the discontinued LLVM Phabricator instance.

[LLParser] Delete temporary CallInst when error occurs in ParseCall
ClosedPublic

Authored by qiucf on Apr 17 2020, 3:41 AM.

Details

Summary

Below is the motivating test case:

define dso_local i64 @test_lrint_fast(double %d) local_unnamed_addr {
entry:
  %0 = call fast i64 @llvm.lrint.i64.f64(double %d)
  ret i64 %0
}

declare i64 @llvm.lrint.i64.f64(double)

Compile it with llc, we see:

While deleting: double %
Use still stuck around after Def is destroyed:  <badref> = call addrspace(0) i64 @llvm.lrint.i64.f64(double %0)
Assertion failed: (materialized_use_empty() && "Uses remain when a value is destroyed!"), function ~Value, file llvm-project/llvm/lib/IR/Value.cpp, line 96.

The reason is we still have an undeleted value referencing the argument.

Diff Detail

Event Timeline

qiucf created this revision.Apr 17 2020, 3:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 17 2020, 3:41 AM
arsenm requested changes to this revision.Apr 17 2020, 6:57 AM

Needs test

This revision now requires changes to proceed.Apr 17 2020, 6:57 AM

Should we fix the definition of FPMathOperator and/or change the IR verifier instead? How did that call acquire FMF in the first place?

qiucf updated this revision to Diff 259460.Apr 22 2020, 8:01 PM

Add a test

qiucf added a comment.Apr 22 2020, 8:02 PM

Should we fix the definition of FPMathOperator and/or change the IR verifier instead? How did that call acquire FMF in the first place?

It's not correct IR. However, that's a crash we'd like to avoid.

I was not clear we can't add FMF to functions returning int. We can only add enable-unsafe-fp-math to use native instruction instead of libcall (at least, on PPC), but the option is deprecated. That seems to be an issue.

It's an improvement in the crash experience, so that's ok with me. But see if @arsenm agrees.
Still need to decide how to apply/verify FMF in general.

arsenm accepted this revision.Jun 15 2020, 1:18 PM

LGTM

This revision is now accepted and ready to land.Jun 15 2020, 1:18 PM
This revision was automatically updated to reflect the committed changes.