Fwd: Question of JITC

[lyh.kernel]

After I sent the email, I realized that I haven't cc to octave-maintainer.

---------- Forwarded message ----------
From: lyh.kernel <address@hidden>
Date: 2013/7/23
Subject: Re: Question of JITC
To: Max Brister <address@hidden>

Hello Max,

I would like to remove interrupt handler of JITC linear IR because I want to focus on your implementation rather than distracted by interrupt handler.

The interrupt handler is part of the implementation. For example, the interrupt check is added for the for loop here[1]. You can see the code generation (octave linear IR -> LLVM IR) here[2]. If you wanted to remove the interrupt check from LLVM, I guess you could comment out the switch statement at [2].

 

I modify the function void jit_convert::visit_while_command (tree_while_command& wc):pt-jit.cc:

#if 0
  if (! all_breaking || continues.size ())
    {
      jit_block *interrupt_check
        = factory.create<jit_block> ("interrupt_check");
      blocks.push_back (interrupt_check);
      finish_breaks (interrupt_check, continues);
      if (! all_breaking)
        block->append (factory.create<jit_branch> (interrupt_check));

      block = interrupt_check;
      jit_error_check *ec
        = factory.create<jit_error_check> (jit_error_check::var_interrupt,
                                           cond_check, final_block);
      block->append (ec);
    }
#else
  block->append (factory.create<jit_branch> (cond_check));
#endif

After I add this modification. There is no JITC Linear IR related to interrupt/error handler. Is it correct position to disable interrupt/error support? If it is, I would like to add a option like disable_jit_handle_error(1) or disable_jit_handle_interrupt(1).

 

I have post my execution result on my GSoC blog (http://octave-jitc.blogspot.tw/). You may take a look. Any suggestion is welcomed.

That is great! I'm glad to see you have made significant progress adding functionality to JIT.

For the switch statement, you did the correct thing by treating it like a series of if statements. Remember, we still run LLVMs optimization passes, it seems to me like the correct location for the implementation of bit tests, binary trees, ect would be an LLVM optimization pass. In fact, LLVM probably already has these implemented as an optimization pass, we might need to enable it though. (I wouldn't worry about that to much now, however). 

As far as I know, these optimizations I mentioned is used to lower LLVM switch IR. But type of label in LLVM switch IR must be int constant. I am afraid that we cannot represent octave switch statement with LLVM switch IR because type of label could be an _expression_ rather than int constant, which means we cannot get benefit of this LLVM optimization. 

On the other hand. I read the GSoC report of you and I know you have support some other types rather than scalar (double). But I have no idea how to test it. Would you mind to tell me? It is important for me to trace your implementation if I want to add integer type support.

Could you give me some small test input to test other types you support rather than scalar? Because I am not a octave/matlab expert. All the tests I prepared are scalar type, I even don't know how to write test for int type.

Thanks a lot