amishne/llvm-ir-editor

Implicit basic block names are calculated incorrectly

thSoft opened this issue · 5 comments

The inference of names of unlabeled basic blocks is not properly documented in the Language Reference. The algorithm is outlined here. Unfortunately, ReverseElementIterable does not take temporary local variables into account, which results in incorrect numbering of basic blocks without label and therefore linking errors when they are referenced.

Could you provide a code sample (IR snippet) which demonstrates the issue? Because ReverseElementIterable should take both unnamed locals and unnamed BBs into account...

Thanks for the quick answer! Let's take the example of the mentioned issue:

define i32 @foo(i32 %a, i32 %b) nounwind ssp uwtable {
  %1 = alloca i32, align 4
  %2 = alloca i32, align 4
  %3 = alloca i32, align 4
  store i32 %a, i32* %2, align 4
  store i32 %b, i32* %3, align 4
  %4 = load i32* %2, align 4
  %5 = call i32 @bar(i32 %4)
  %6 = icmp ne i32 %5, 0
  br i1 %6, label %7, label %11

; <label>:7                                       ; preds = %0
  %8 = load i32* %2, align 4
  %9 = load i32* %3, align 4
  %10 = add nsw i32 %8, %9
  store i32 %10, i32* %1
  br label %15

; <label>:11                                      ; preds = %0
  %12 = load i32* %2, align 4
  %13 = load i32* %3, align 4
  %14 = mul nsw i32 %12, %13
  store i32 %14, i32* %1
  br label %15

; <label>:15                                      ; preds = %11, %7
  %16 = load i32* %1
  ret i32 %16
}

declare i32 @bar(i32)

The basic blocks should have the names %0, %7, %11, %15 respectively. Instead, their names become %0, %1, %2, %3.

It works correctly for me... see the items outlined in red in this screenshot:

unnamed_bbs

The outline view shows them correctly, and no error is reported in the editor (and you can ctrl-click the BB label in the editor or just hover over it to see it is associated with the correct BB).

Have you verified that you are running the latest version?

Sorry for the false report, this bug is not present here but in my fork, where I migrated from a generated metamodel to an imported one and "normalized" the somewhat complicated Instruction rule/type hierarchy, which introduced changes in the node model. This broke the ReverseElementIterable logic which makes runtime assumptions about the structure of the parse tree.

No worries, ReverseElementIterable is very sensitive to node model changes.