added ability to iterate over basic block's predecessors

[carpall]

Like in the C api, basic blocks have a list of predecessors.
Predecessors are all the basic blocks which refer to a specific basic block.
For example:

define dso_local i32 @main() #0 !dbg !9 {
  %1 = alloca i32, align 4
  %2 = alloca i32, align 4
  store i32 0, i32* %1, align 4
  call void @llvm.dbg.declare(metadata i32* %2, metadata !14, metadata !DIExpression()), !dbg !15
  store i32 1, i32* %2, align 4, !dbg !15
  %3 = load i32, i32* %2, align 4, !dbg !16
  %4 = icmp ne i32 %3, 0, !dbg !16
  br i1 %4, label %5, label %6, !dbg !18

5:                                                ; predecessors = %0
  store i32 0, i32* %2, align 4, !dbg !19
  br label %7, !dbg !21

6:                                                ; predecessors = %0
  store i32 1, i32* %2, align 4, !dbg !22
  br label %7

7:                                                ; predecessors = %6, %5
  %8 = load i32, i32* %1, align 4, !dbg !24
  ret i32 %8, !dbg !24
}

[carpall]

There's a problem with tests I think, the change I made has no side effects, it can't make crash tests

[gmarkall]

Many thanks for the PR!

I'm finding the API confusing - wouldn't it be more straightforward if blocks had a method to add predecssors, rather than the IRBuilder having a set_pred method that sets the predecessor of the passed block as the current block? (Does the C API do things this way?)

Could you also include tests and documentation for the additional feature please?

[esc]

@carpall thank you for submitting this!

It seems like flake8 is still complaining/nitpicking:

llvmlite/ir/builder.py:826:12: E713 test for membership should be 'not in'
llvmlite/ir/builder.py:845:30: E702 multiple statements on one line (semicolon)

[carpall]

fixing problems for flake8

[esc]

Could you also include tests and documentation for the additional feature please?

I second that, thank you @gmarkall -- we will need some tests. I do like the feature though.

[carpall]

Could you also include tests and documentation for the additional feature please?

I second that, thank you @gmarkall -- we will need some tests. I do like the feature though.

how can I add documentation for this little feature? I didn't find something about contributions on the readme

[esc]

Could you also include tests and documentation for the additional feature please?

I second that, thank you @gmarkall -- we will need some tests. I do like the feature though.

how can I add documentation for this little feature? I didn't find something about contributions on the readme

https://llvmlite.readthedocs.io/en/latest/contributing.html <-- maybe a bit out of date, unfortunately.

[carpall]

Could you also include tests and documentation for the additional feature please?

I second that, thank you @gmarkall -- we will need some tests. I do like the feature though.

how can I add documentation for this little feature? I didn't find something about contributions on the readme

https://llvmlite.readthedocs.io/en/latest/contributing.html <-- maybe a bit out of date, unfortunately.

Now I have no time to edit the documentation, about the test I think it was so small as change to be tested
documentation:
.has_predecessors: returns true whether the block has predecessors
.predecessors: returns a list of predecessors of self block
precedessors are blocks which contain a branch to a specified block
ex:

entry:
  br  label %bb0
bb0:
  br i1 %0, label %bb1, label %bb2 ; bb1.predecessors: [bb0], bb2.predecessors: [bb0], bb0.predecessors: [entry]

[gmarkall]

Many thanks for the update!

Now I have no time to edit the documentation

No problem - when you do have time, you can update this PR and ping either myself or @esc for us to review the new changes please?

about the test I think it was so small as change to be tested

In general all changes need to be tested - this helps in multiple ways:

• Foremost, it demonstrates that the additions function as expected by both the submitter and the reviewer.
• To some extent, tests provide an example of the intended operation of a new API - adding tests also helps to think about edge cases and how they might be handled or might break down.
• It also ensures the new functionality continues to work when the code is modified in the future - your changes may work now, but someone else less familiar with the code or this specific API could inadvertently break it with future changes. In general it's very difficult even for experienced developers to avoid breaking things that have no tests.

If you'd like to proceed with the PR (adding tests and documentation), could you please also respond to the question about the API design from above? This was:

I'm finding the API confusing - wouldn't it be more straightforward if blocks had a method to add predecessors, rather than the IRBuilder having a set_pred method that sets the predecessor of the passed block as the current block? (Does the C API do things this way?)

Many thanks for your efforts - do let us know if you need any further info / clarification.