octave-maintainers
[Top][All Lists]
Advanced

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

Re: Question of JITC


From: lyh.kernel
Subject: Re: Question of JITC
Date: Sat, 3 Aug 2013 22:13:05 +0800

Hello Max,

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.

If we do have double constants, which are well ordered. We could generate the switch statement tests as a binary search tree. It could reduce the time complexity from O(n) to O(log n).

But as you say previously, this could be done for later optimization because we have good performance over non-JIT octave now.

Thanks a lot.

reply via email to

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