llvm dev - Jul 2019 - What can cause llc to throw an error for instruction numbering?

I duplicated an instruction in llvm and changed its opcode by following the
guide at https://llvm.org/docs/ExtendingLLVM.html (Adding a new instruction) and
then fixed the dependencies that caused an error when building. Now the modified
llvm builds but throws but now throws the error:
llc: error: llc: check.ll:12:3: error: instruction expected to be numbered
'%5'

  %4 = alloca i32, align 4

What changes/modification would cause this error to show up? I was thinking that
SelectionDAGBuilder would cause this as it parses IR to an optimized version but
not sure.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190708/82638812/attachment.html>

Hi Kaarthik,

On Mon, 8 Jul 2019 at 18:18, Kaarthik Alagapan via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> llc: error: llc: check.ll:12:3: error: instruction expected to be numbered
'%5'
>
>   %4 = alloca i32, align 4
>
>
> What changes/modification would cause this error to show up? I was thinking
that SelectionDAGBuilder would cause this as it parses IR to an optimized
version but not sure.
I think only the IR parser (lib/AsmParser/LLParser.cpp) produces that
error, which is well before anything in SelectionDAG runs.

Did you maybe intend to create an instruction that doesn't produce a
value (like "store" for example) but start off by copying one that did
produce a value? In that case, if your IR was really

    ...
    %3 = ...
    my_shiny_inst i32 %a, %b
    %4 = alloca i32
    ...

then during parsing LLVM will have decided that my_shiny_inst really
produced %4 (it wouldn't complain about "%4 =" being missing at
that
point), but when the next instruction claimed to be %4 it would
produce the error you're describing.

Obviously the same situation could occur if your instruction really
does produce a value but you either intentionally or accidentally
omitted the "%4 =" in your test-case IR.

Cheers.

Tim.

Hi Tim,
Thank you for that. I was just trying to replicate the branch instruction under
a new opcode, so I don’t think that returns a value. Plus the code I was testing
out didn’t have a br or my newly added instruction but it still threw that error
at me. Here’s the IR code I tested:
; ModuleID = ‘cc.c’
source_filename = “cc.c”
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128”
target triple = "x86_64-pc-linux-gnu”

; Function Attrs: noinline nounwind optnone uwtable
define i32 @main(i32, i8**) #0 {
  %3 = alloca i32, align 4
  %4 = alloca i8**, align 8
  store i32 %0, i32* %3, align 4
  store i8** %1, i8*** %4, align 8
  ret i32 0
}

attributes #0 = { noinline nounwind optnone uwtable
"correctly-rounded-divide-sqrt-fp-math"="false"
"disable-tail-calls"="false"
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false"
"no-jump-tables"="false"
"no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false"
"no-trapping-math"="false"
"stack-protector-buffer-size"="8"
"target-cpu"="x86-64"
"target-features"="+fxsr,+mmx,+sse,+sse2,+x87"
"unsafe-fp-math"="false" "use-soft-float”=“false” }

!llvm.module.flags = !{!0}
!llvm.ident = !{!1}

!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{!"clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)”}

I tested a longer IR code and if I fixed one of the instruction number to the
expected one (say from %4 to %5), it tells me that the following line’s
instruction number must be the nest odd number (that %5 should be %7). I am
guessing that my modification is causing a value to be produced after each
allocation instruction, would that still be under LLParser?

Thank you,
Kaarthik.
On Jul 8, 2019, 1:47 PM -0400, Tim Northover <t.p.northover at gmail.com>,
wrote:
Hi Kaarthik,

On Mon, 8 Jul 2019 at 18:18, Kaarthik Alagapan via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
llc: error: llc: check.ll:12:3: error: instruction expected to be numbered
'%5'

%4 = alloca i32, align 4


What changes/modification would cause this error to show up? I was thinking that
SelectionDAGBuilder would cause this as it parses IR to an optimized version but
not sure.

I think only the IR parser (lib/AsmParser/LLParser.cpp) produces that
error, which is well before anything in SelectionDAG runs.

Did you maybe intend to create an instruction that doesn't produce a
value (like "store" for example) but start off by copying one that did
produce a value? In that case, if your IR was really

...
%3 = ...
my_shiny_inst i32 %a, %b
%4 = alloca i32
...

then during parsing LLVM will have decided that my_shiny_inst really
produced %4 (it wouldn't complain about "%4 =" being missing at
that
point), but when the next instruction claimed to be %4 it would
produce the error you're describing.

Obviously the same situation could occur if your instruction really
does produce a value but you either intentionally or accidentally
omitted the "%4 =" in your test-case IR.

Cheers.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190708/b1b72b37/attachment.html>