[llvm-dev] What can cause llc to throw an error for instruction numbering?

[Kaarthik Alagapan via llvm-dev]

Thank you for that suggestion, but I tried opt -instnamer <file.ll> and it threw that same error unfortunately (for running opt -instnamer)

Regards,
Kaarthik.
On Jul 8, 2019, 3:32 PM -0400, Krzysztof Parzyszek <kparzysz at quicinc.com>, wrote:
The problem is that there are some unnamed values in the listing, that are not explicitly printed.  In reality you have

define i32 @main(i32 %0, i8** %1) #0 {
%2:
  %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
}

Unnamed values are numbered from %0, and the numbers must be consecutive integers.  Producing unnamed values is generally a bad idea for the reasons you’re experiencing.  You can always run the ll file through “opt -instnamer” (e.g. opt -instnamer -S < inp.ll > out.ll), and that will rename all instructions (including giving names to the unnamed ones).


--
Krzysztof Parzyszek  kparzysz at quicinc.com<mailto:kparzysz at quicinc.com>   LLVM compiler development

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Kaarthik Alagapan via llvm-dev
Sent: Monday, July 8, 2019 1:32 PM
To: Tim Northover <t.p.northover at gmail.com>
Cc: llvm-dev at lists.llvm.org
Subject: [EXT] Re: [llvm-dev] What can cause llc to throw an error for instruction numbering?

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<mailto: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<mailto: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/33e22a58/attachment.html>