llvm dev - Feb 2010 - [LLVMdev] Code generation problem

I was testing my implementation of the usual ternary function just
now, and it's giving the wrong answer; I would attribute this to an
error in my parser/abstract syntax tree code, but looking at the
output, as far as I can see, the intermediate code is correct at the
point where I hand it to LLVM's JIT. Could someone look and see if I'm
doing something wrong, misunderstanding the semantics of the
intermediate code format or something?

C:\aklo>ak
Aklo version 0 (32 bit)
> 1?2?3:4:5
declare void @abort()

define i32 @_main() {
  br i32 1, label %1, label %6

; <label>:1                                       ; preds = %0
  br i32 2, label %2, label %3

; <label>:2                                       ; preds = %1
  br label %4

; <label>:3                                       ; preds = %1
  br label %4

; <label>:4                                       ; preds = %3, %2
  %5 = phi i32 [ 3, %2 ], [ 4, %3 ]               ; <i32> [#uses=1]
  br label %7

; <label>:6                                       ; preds = %0
  br label %7

; <label>:7                                       ; preds = %6, %4
  %8 = phi i32 [ %5, %4 ], [ 5, %6 ]              ; <i32> [#uses=1]
  ret i32 %8
}
4

(result is 4, should be 3)

On Feb 8, 2010, at 1:53 PM, Russell Wallace wrote:
> I was testing my implementation of the usual ternary function just
> now, and it's giving the wrong answer; I would attribute this to an
> error in my parser/abstract syntax tree code, but looking at the
> output, as far as I can see, the intermediate code is correct at the
> point where I hand it to LLVM's JIT. Could someone look and see if
I'm
> doing something wrong, misunderstanding the semantics of the
> intermediate code format or something?
The condition on a branch instruction is not evaluated with C condition
semantics.  It must be of i1 type, i.e. either true or false.  Your IR should
(presumably) be more like:

  %c1 = icmp ne i32 1, i32 0
   br i1 %c1, label %yes, label %no
yes:
  %c2 = icmp ne i32 2, i32 0
  br i1 %c2, ....

Also, if you are producing IR yourself, you should always be running the IR
verification pass (at least in debug mode), which should catch structural
problems like this (and many others).

John.

Oh! Okay, thanks, I'll fix it up to do that then.

Any chance verifyFunction could be tightened up to catch this case?
I'm currently running all my generated code through it, and it passes
the i32 conditional without complaint.

On Mon, Feb 8, 2010 at 10:07 PM, John McCall <rjmccall at apple.com>
wrote:
> On Feb 8, 2010, at 1:53 PM, Russell Wallace wrote:
>> I was testing my implementation of the usual ternary function just
>> now, and it's giving the wrong answer; I would attribute this to an
>> error in my parser/abstract syntax tree code, but looking at the
>> output, as far as I can see, the intermediate code is correct at the
>> point where I hand it to LLVM's JIT. Could someone look and see if
I'm
>> doing something wrong, misunderstanding the semantics of the
>> intermediate code format or something?
>
> The condition on a branch instruction is not evaluated with C condition
> semantics.  It must be of i1 type, i.e. either true or false.  Your IR
should
> (presumably) be more like:
>
>  %c1 = icmp ne i32 1, i32 0
>   br i1 %c1, label %yes, label %no
> yes:
>  %c2 = icmp ne i32 2, i32 0
>  br i1 %c2, ....
>
> Also, if you are producing IR yourself, you should always be running the IR
> verification pass (at least in debug mode), which should catch structural
> problems like this (and many others).
>
> John.
>

Hi Russell,
>   br i32 1, label %1, label %6
if you build LLVM with checking enabled, then you would not have been able to
create this bogus branch instruction: the BranchInst constructors assert if the
condition does not have type i1.

This does raise a philosophical question though: should the verifier try to
catch mistakes that constructors would catch if assertions are turned on?

Ciao,

Duncan.

Oh! Now I get it, that would be with the debug build of LLVM. Never
mind the request then, "use the debug build if you want full error
checking" is perfectly reasonable. I'll start doing that for the
moment.

On Wed, Feb 10, 2010 at 10:18 AM, Duncan Sands <baldrick at free.fr>
wrote:
> Hi Russell,
>
>>  br i32 1, label %1, label %6
>
> if you build LLVM with checking enabled, then you would not have been able
> to
> create this bogus branch instruction: the BranchInst constructors assert if
> the
> condition does not have type i1.
>
> This does raise a philosophical question though: should the verifier try to
> catch mistakes that constructors would catch if assertions are turned on?
>
> Ciao,
>
> Duncan.
>

> This does raise a philosophical question though: should the verifier try to
> catch mistakes that constructors would catch if assertions are turned on?
Yes please!

John

Duncan Sands wrote:
> Hi Russell,
>
>>    br i32 1, label %1, label %6
>
> if you build LLVM with checking enabled, then you would not have been able
to
> create this bogus branch instruction: the BranchInst constructors assert if
the
> condition does not have type i1.
>
> This does raise a philosophical question though: should the verifier try to
> catch mistakes that constructors would catch if assertions are turned on?
Yes, absolutely. In my ideal world you would be able to build a 
Release-Asserts LLVM and load a .bc file and run it through the verifier 
and have it catch any invalid or malformed bitcode.

Nick
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>