thr3ads.net - llvm dev - [llvm-dev] What can cause llc to throw an error for instruction numbering? [Jul 2019]

If this information is useful, please help other people find it:
Share via:

Kaarthik Alagapan via llvm-dev

2019-Jul-08 18:31 UTC

[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>,
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>

Tim Northover via llvm-dev

2019-Jul-08 18:47 UTC

head link

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

On Mon, 8 Jul 2019 at 19:31, Kaarthik Alagapan <kaarthik at
knights.ucf.edu> wrote:> 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?
I think so. The parsing code is the first thing run on any IR, and
produces the internal representation everything else might use. So
there's just not really any other part of LLVM that could be involved.

The code you're looking for is in the function "SetInstName", and
its
diagnostics seem to be derived directly from NumberedVals.size(). So
if it was me I'd be looking for two calls to SetInstName per
instruction, or maybe an out-of-band push to that variable.

Obviously I can't see what code you've written, but it might be worth
double checking any switch statements you've modified to make sure you
haven't left a fallthrough where it shouldn't be. That's the kind of
mistake I could see causing this.

Cheers.

Tim.

Krzysztof Parzyszek via llvm-dev

2019-Jul-08 19:32 UTC

head link

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

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/0bb0dd6a/attachment.html>

Tim Northover via llvm-dev

2019-Jul-08 19:39 UTC

head link

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

On Mon, 8 Jul 2019 at 20:32, 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
I don't think that works as a complete explanation, but it does
strongly suggest another avenue to investigate: what if LLVM is
starting a new basic block after every instruction for some reason?
Then LLVM would think it had

    define i32 @main(i32 %, i8** %1) {
     %2:
       %3 = alloca i32, align 4
     %4:
       %5 = alloca i8**, align 8
     %6:
        ...

Watching NumberedVals would still reveal this (I think), but not
SetInstName. And it would suggest looking at any extra code that might
affect when LLVM starts a new block.

Cheers.

Tim.

Kaarthik Alagapan via llvm-dev

2019-Jul-08 19:43 UTC

head link

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

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>

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

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

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

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

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

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