RVCの判定条件に付いて，もう少し考えを推し進めた．
まず，insn_rvcの生成方法だが，これを正確に生成することがまず難しい．
例えばデコードブロックのサイズが128-bitの場合，8つの16-bitブロックに分割してRVC判定を行うことになる．
しかし，ここでRVC判定の疑似エラーが発生する可能性がある． それは，RVI命令であっても16ビット境界の2ビットが11以外ならば，RVC命令と判定してしまう点だ．
LUI a5, 0x0 // 0x0000_07b7
このLUI命令は32ビットで構成され，2つの16ビットブロックで構成される．0x07b7は下位2ビットが11なのでRVI命令と判定されるが，上位16ビットの下位2ビットは00なのでRVC命令と判定してしまう．すると，全体的な命令の切り出しが誤ってしまう．
ここでポイントなのは，RVCではない，つまりinsn_rvcにおける0はかならず偶数回連続するということだ．
さっきのRVC判定のビット列で，例えばビット6が誤ってRVC命令だと判定されたとする．
6ビット目よりも前の5:0の6ビットで，RVC=1が3つあるので，RVC命令が3つ存在していることがわかる．
そうすると，6ビット目（＝偶数ビット）はRVI命令の後半16ビットとして使われるはずなので，ここは必ず0となるはずである．
問題はこれが2つの位置で同時に発生するとどうなるか．
まず，ビット2はさっきの公式で，1:0の1ビットの数が奇数個なので，自分は0にならなければならない．
するとそれに応じてまた Prefix Sum の結果が変わってしまい，後半のビット6の結果は再計算した Prefix Sum の結果に応じて再び判定する必要がある． これは論理のクリティカルパスとなってしまうので，やめたほうがいい．
うーん，やはりRVCの切り出し判定を正しく実行する方法を考えたほうが得策か．
