Partial evaluator too eager cont.

[richardmembarth]

The following example should specialize specialize, but it doesn't since PE is too eager.

extern "thorin" {
    fn pe_info[T](&[u8], T) -> (); 
}

enum Num { one, two }
fn num2idx(n: Num) -> i32 { match n { Num::one => 0, _ => 1 } } 

fn @test(n: Num) -> i32 {
    match n { 
        Num::one => {
            let i = num2idx(n);

            fn @(?i) specialize(x: i32) -> i32 {
                pe_info("x", x); 
                if x < 0 { 
                    x   
                } else {
                    specialize(x-1)
                }   
            }   

            pe_info("i", i); 
            specialize(i)
        },  
        _ => 0
    }   
}

extern
fn start() -> i32 {
    test(Num::one) as i32 
}

This produces:

#  impala -log-level info -emit-llvm test.impala 
I:test.impala:22 col 13 - 27: pe_info: i: qs32 0
I:test.impala:14 col 17 - 31: pe_info not constant: x: x_348

While it should yield (removing @(?i) or replacing by @(?x)):

# impala -log-level info -emit-llvm test.impala 
I:test.impala:22 col 13 - 27: pe_info: i: qs32 0
I:test.impala:14 col 17 - 31: pe_info: x: qs32 0
I:test.impala:14 col 17 - 31: pe_info: x: qs32 -1

This seems to be related to #90.

[leissa]

The problem is that the filter (formerly known as pe_policy) is not a real operand of a continuation. It should be, but it isn't. Changing this would introduce many subtle bugs in other passes because currently we assume that op(0) of a continuation is its callee and op(1) to op(1+n-1) is its argument list. We would have to do this:

op(0) -> filter
op(1) -> callee
op(2) to op(2+n-1) -> args

Unless this is a really pressing issue I wouldn't spend time on this because in CoC it is correctly modeled.

[richardmembarth]

Not really urgent. Pops up once in a while for more complex code (which gets then not optimized). Is there a timeline for CoC integration?

[leissa]

No yet, but I need more help.