How to get the case value from Machine Instruction

Hi, guys
I am interesting about how to get the switch case value form the Machine Instruction.

I know the switch will be converted to jump-table in the Machine Instruction.
And in the phase CodeGen , the case-value of SwitchInst can get esasly.
but it seems no case -value in Machine Instruction.

The MI as follows:
Frame Objects:

fi#0: size=1, align=0, at location [SP]
fi#1: size=4, align=4, at location [SP+8]
fi#2: size=4, align=4, at location [SP+4]
fi#3: size=4, align=4, at location [SP]
Jump Tables:
%jump-table.0: %bb.2 %bb.3 %bb.4 %bb.5

%bb.0: derived from LLVM BB %0
%r0 = MOVi 0, 14, %noreg, %noreg
STRi12 %r0, %stack.1, 14, %noreg
%r0 = MOVi 4, 14, %noreg, %noreg
STRi12 %r0, %stack.2, 14, %noreg
%r0 = LDRi12 %stack.2, 14, %noreg
%r0 = SUBri %r0, 1, 14, %noreg, %noreg
CMPri %r0, 3, 14, %noreg, implicit-def %cpsr
STRi12 %r0, %stack.3, 14, %noreg
Bcc %bb.6, 8, %cpsr
Successors according to CFG: %bb.6 %bb.1

%bb.1: derived from LLVM BB %1
Predecessors according to CFG: %bb.0
%1:gprnopc = LEApcrelJT %jump-table.0, 14, %noreg
%2:gprnopc = LDRrs killed %0:gprnopc, %1, 0, 14, %noreg; mem:LD4[JumpTable]
BR_JTr killed %2, %jump-table.0
Successors according to CFG: %bb.2(?%) %bb.3(?%) %bb.4(?%) %bb.5(?%)

%bb.2: derived from LLVM BB %2
Predecessors according to CFG: %bb.1
%r0 = LDRi12 %stack.2, 14, %noreg
%r0 = ADDri %r0, 11, 14, %noreg, %noreg
STRi12 %r0, %stack.2, 14, %noreg
B %bb.6
Successors according to CFG: %bb.6

%bb.3: derived from LLVM BB %3
Predecessors according to CFG: %bb.1
%r0 = LDRi12 %stack.2, 14, %noreg
%r0 = ADDri %r0, 12, 14, %noreg, %noreg
STRi12 %r0, %stack.2, 14, %noreg
B %bb.6
Successors according to CFG: %bb.6

%bb.4: derived from LLVM BB %4
Predecessors according to CFG: %bb.1
%r0 = LDRi12 %stack.2, 14, %noreg
%r0 = ADDri %r0, 13, 14, %noreg, %noreg
STRi12 %r0, %stack.2, 14, %noreg
B %bb.6
Successors according to CFG: %bb.6

%bb.5: derived from LLVM BB %5
Predecessors according to CFG: %bb.1
%r0 = LDRi12 %stack.2, 14, %noreg
%r0 = ADDri %r0, 14, 14, %noreg, %noreg
STRi12 %r0, %stack.2, 14, %noreg
Successors according to CFG: %bb.6

%bb.6: derived from LLVM BB %6
Predecessors according to CFG: %bb.0 %bb.2 %bb.3 %bb.4 %bb.5
%r0 = LDRi12 %stack.2, 14, %noreg
BX_RET 14, %noreg

I hope to get the Case value from the MI,
Thanks,
yaoxiao

Some glitch in the emailer? I have received this message 3 times in a row!?

I think that by the time it gets as far as MI-level there is no reversible method of determining the ‘case’ label at all. The reason I say this, is that I have often seen optimisations that coalesce groups of values into interesting logical tests and jump-tables are completely avoided. For example, a simple range like:

switch(n) {

case 8:

case 9:

case 10:

case 11:

case 12:

case 13:

case 14:

case 15:

…action…

}

is quite likely to become (equivalent to):

if ((n & 0xFFFFFF8) == 0x00000008) …action…

so the ‘case’ logic of the original expression is lost; and there are other logical reductions a lot less obvious than this. I expect that at IR-level, especially pre-SCEV that the ‘case’ specific information might still be available but at MI-level it has already been lost. The debug information might still retain some back-association, but I am not particularly familiar with Dwarf.

MartinO

Some glitch in the emailer? I have received this message 3 times in a row!?

I think that by the time it gets as far as MI-level there is no reversible method of determining the ‘case’ label at all. The reason I say this, is that I have often seen optimisations that coalesce groups of values into interesting logical tests and jump-tables are completely avoided. For example, a simple range like:

switch(n) {

case 8:

case 9:

case 10:

case 11:

case 12:

case 13:

case 14:

case 15:

…action…

}

is quite likely to become (equivalent to):

if ((n & 0xFFFFFF8) == 0x00000008) …action…

so the ‘case’ logic of the original expression is lost; and there are other logical reductions a lot less obvious than this. I expect that at IR-level, especially pre-SCEV that the ‘case’ specific information might still be available but at MI-level it has already been lost. The debug information might still retain some back-association, but I am not particularly familiar with Dwarf.

MartinO

Some glitch in the emailer? I have received this message 3 times in a row!?

I think that by the time it gets as far as MI-level there is no reversible method of determining the ‘case’ label at all. The reason I say this, is that I have often seen optimisations that coalesce groups of values into interesting logical tests and jump-tables are completely avoided. For example, a simple range like:

switch(n) {

case 8:

case 9:

case 10:

case 11:

case 12:

case 13:

case 14:

case 15:

…action…

}

is quite likely to become (equivalent to):

if ((n & 0xFFFFFF8) == 0x00000008) …action…

so the ‘case’ logic of the original expression is lost; and there are other logical reductions a lot less obvious than this. I expect that at IR-level, especially pre-SCEV that the ‘case’ specific information might still be available but at MI-level it has already been lost. The debug information might still retain some back-association, but I am not particularly familiar with Dwarf.

MartinO