llvm dev - Jun 2019 - Instcombine Creating Illegal Code? (in LLVM 7)

Hi all,

I was playing around with LLVM 7 and I discovered something that seems to
me to be a bug -- or at least something that I don't understand.

Take the following valid simple program and run -instcombine on it

declare i8* @malloc(i64)

define void @caller() {
entry:
  call void @callee()
  ret void
}

define fastcc void @callee() {
entry:
  %malloccall = call i8* @malloc(i64 9)
  store i8 0, i8* %malloccall
  ret void
}


It get's transformed into the following invalid code after the optimization
(now having an illegal store):

; ModuleID = 'blarg.ll'
source_filename = "blarg.ll"

declare i8* @malloc(i64)

define void @caller() {
entry:
  store i1 true, i1* undef, align 1
  ret void
}

define fastcc void @callee() {
entry:
  ret void
}

Anyone seen this before and/or could shed some light on this behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190628/2d8693b6/attachment.html>

I think the issue here is that callee is declared with the fastcc calling
convention, but the call in caller doesn't use fastcc. So InstCombine
deleted the call and is emitting the store i1 true, i1* undef, align 1 to
indicate to a different pass that this code is unreachable.

~Craig


On Fri, Jun 28, 2019 at 12:52 AM William Moses via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> I was playing around with LLVM 7 and I discovered something that seems to
> me to be a bug -- or at least something that I don't understand.
>
> Take the following valid simple program and run -instcombine on it
>
> declare i8* @malloc(i64)
>
> define void @caller() {
> entry:
>   call void @callee()
>   ret void
> }
>
> define fastcc void @callee() {
> entry:
>   %malloccall = call i8* @malloc(i64 9)
>   store i8 0, i8* %malloccall
>   ret void
> }
>
>
> It get's transformed into the following invalid code after the
> optimization (now having an illegal store):
>
> ; ModuleID = 'blarg.ll'
> source_filename = "blarg.ll"
>
> declare i8* @malloc(i64)
>
> define void @caller() {
> entry:
>   store i1 true, i1* undef, align 1
>   ret void
> }
>
> define fastcc void @callee() {
> entry:
>   ret void
> }
>
> Anyone seen this before and/or could shed some light on this behavior.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190628/b93baf6b/attachment-0001.html>

I see, that makes sense.

Would it be worthwhile checking that caller/callee's match as part of the
verifier or is there a reason that it simply emits undefined behavior?

On Fri, Jun 28, 2019 at 1:26 AM Craig Topper <craig.topper at gmail.com>
wrote:
> I think the issue here is that callee is declared with the fastcc calling
> convention, but the call in caller doesn't use fastcc. So InstCombine
> deleted the call and is emitting the store i1 true, i1* undef, align 1 to
> indicate to a different pass that this code is unreachable.
>
> ~Craig
>
>
> On Fri, Jun 28, 2019 at 12:52 AM William Moses via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I was playing around with LLVM 7 and I discovered something that seems
to
>> me to be a bug -- or at least something that I don't understand.
>>
>> Take the following valid simple program and run -instcombine on it
>>
>> declare i8* @malloc(i64)
>>
>> define void @caller() {
>> entry:
>>   call void @callee()
>>   ret void
>> }
>>
>> define fastcc void @callee() {
>> entry:
>>   %malloccall = call i8* @malloc(i64 9)
>>   store i8 0, i8* %malloccall
>>   ret void
>> }
>>
>>
>> It get's transformed into the following invalid code after the
>> optimization (now having an illegal store):
>>
>> ; ModuleID = 'blarg.ll'
>> source_filename = "blarg.ll"
>>
>> declare i8* @malloc(i64)
>>
>> define void @caller() {
>> entry:
>>   store i1 true, i1* undef, align 1
>>   ret void
>> }
>>
>> define fastcc void @callee() {
>> entry:
>>   ret void
>> }
>>
>> Anyone seen this before and/or could shed some light on this behavior.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190628/ff097a16/attachment.html>