LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 32136 - Copy Elision code produces assertion failure for i1 parameters
Summary: Copy Elision code produces assertion failure for i1 parameters
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Common Code Generator Code (show other bugs)
Version: 4.0
Hardware: PC All
: P enhancement
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-03 16:41 PST by Matthias Braun
Modified: 2017-03-06 11:33 PST (History)
2 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Braun 2017-03-03 16:41:14 PST
Swift triggers an assert in the copy elision code now. We believe this to be cause by i1 parameters. I was able to craft a small reproducer:

target triple = "x86_64-apple-macosx"

@g = common global i8* null, align 8

define void @foo(i32 %a0, i32 %a1, i32 %a2, i32 %a3, i32 %a4, i32 %a5, i1 %a6) {
  %tmp = alloca i1, align 4
  store i1 %a6, i1* %tmp, align 4
  %ptr = bitcast i1* %tmp to i8*
  store i8* %ptr, i8** @g, align 8
  ret void
}
Comment 1 Matthias Braun 2017-03-03 17:52:19 PST
I disabled the copy elision optimization for illegal types in r296950.
Comment 2 Reid Kleckner 2017-03-06 10:51:18 PST
I did this a different way in r297045, I think we just needed to use the store size instead of the bit size divided by 8. This also re-enables copy elision from i64s.
Comment 3 Reid Kleckner 2017-03-06 10:51:29 PST
Thanks for the quick workaround!
Comment 4 Matthias Braun 2017-03-06 11:33:30 PST
Thanks for the proper fix! :)