octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question of JITC


From: Max Brister
Subject: Re: Question of JITC
Date: Wed, 24 Jul 2013 14:37:25 -0700




On Tue, Jul 23, 2013 at 4:31 AM, lyh.kernel <address@hidden> wrote:
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).

That looks correct to me. I do not think adding JIT specific functions for this is a good idea. If these functions get added to the Octave interpreter, we could skip emitting the interrupt checking code as a performance optimization. 
 
 
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. 


If the switch conditions are constants in Octave, they will end up as constants in LLVM as well (after type inference and optimizations). For example, look at the "optimized llvm ir" generated by your switch test case, you get the following
%14 = fcmp ueq double %10, 0.000000e+00
  br i1 %14, label %switch_tail, label %if_cond4

It looks to me like LLVM isn't able to further optimize this case because while we do have constants, they are double constants not integers. I don't think we should really wory about this, you are already able to show a large performance over non-JIT Octave.
 
 
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

Matlab's (and therefore Octave's) type system is weird.You can read up on integers here[1]. An example test case might looks something like

a = int32(1);
b = int32(1);

i = int32(0);
bounds = int32(10000)
do
  j = int32(0);
  do
    a = a + b;
    j++;
  until (j == bounds)
  i++;
until (i == bounds)

I don't have Octave available right now, so you may want to check to ensure that is legal Octave code.

--
Max Brister

reply via email to

[Prev in Thread] Current Thread [Next in Thread]