[LLVMdev] Question on optimizeThumb2JumpTables

[Chad Rosier]

Hi Jakob,
You're the unfortunate soul who last touched the constant island pass,
right?  Do you happen to have any insight for Daniel?

 Chad

On Tue, Jul 23, 2013 at 9:55 AM, Daniel Stewart <stewartd at codeaurora.org>wrote:

> In looking at the code in
> ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is
> the following condition for not creating tbb-based jump tables:****
>
> ** **
>
>       // The instruction should be a tLEApcrel or t2LEApcrelJT; we want***
> *
>
>       // to delete it as well.****
>
>       *MachineInstr* *LeaMI = PrevI;****
>
>       *if* ((LeaMI->getOpcode() != *ARM*::tLEApcrelJT &&****
>
>            LeaMI->getOpcode() != *ARM*::t2LEApcrelJT) ||****
>
>           LeaMI->getOperand(0).getReg() != BaseReg)****
>
>         OptOk = *false*;****
>
> ** **
>
>       *if* (!OptOk)****
>
>         *continue*;****
>
> ** **
>
> I am trying to figure out why the restriction of
> LeaMI->getOperand(0).getReg() != BaseReg is there. It seems this is overly
> restrictive. For example, here is a case where it succeeds:****
>
> ** **
>
> 8944B   BB#53: derived from LLVM BB %172****
>
>             Live Ins: %R4 %R6 %D8 %Q5 %R9 %R7 %R8 %R10 %R5 %R11****
>
>             Predecessors according to CFG: BB#52****
>
> 8976B           %R1<def> = t2LEApcrelJT <jt#2>, 2, pred:14, pred:%noreg***
> *
>
> 8992B           %R1<def> = t2ADDrs %R1<kill>, %R10, 18, pred:14,
> pred:%noreg, opt:%noreg****
>
> 9004B           %LR<def> = t2MOVi 1, pred:14, pred:%noreg, opt:%noreg****
>
> 9008B           t2BR_JT %R1<kill>, %R10<kill>, <jt#2>, 2****
>
> ** **
>
> Shrink JT: t2BR_JT %R1<kill>, %R10<kill>, <jt#2>, 2****
>
>      addr: %R1<def> = t2ADDrs %R1<kill>, %R10, 18, pred:14, pred:%noreg,
> opt:%noreg****
>
>       lea: %R1<def> = t2LEApcrelJT <jt#2>, 2, pred:14, pred:%noreg****
>
> ** **
>
> ** **
>
> From this we see that the BaseReg = R1. R1 also happens to be the register
> used in the t2ADDrs calculation as well as defined by the t2LEApcrelJT
> operation. Because R1 is defined by t2LEApcrelJT, the restriction is met.
> ****
>
> ** **
>
> However, in the next example, it fails:****
>
> ** **
>
> 5808B   BB#30: derived from LLVM BB %105****
>
>             Live Ins: %R4 %R6 %D8 %Q5 %R9 %R7 %R8 %R10 %R5 %R11****
>
>             Predecessors according to CFG: BB#29****
>
> 5840B           %R3<def> = t2LEApcrelJT <jt#1>, 1, pred:14, pred:%noreg***
> *
>
> 5856B           %R2<def> = t2ADDrs %R3<kill>, %R7, 18, pred:14,
> pred:%noreg, opt:%noreg****
>
> 5872B           t2BR_JT %R2<kill>, %R7<kill>, <jt#1>, 1****
>
>             Successors according to CFG: BB#90(17) BB#31(17) BB#32(17)
> BB#33(17) BB#34(17) BB#51(17)****
>
> ** **
>
> Here we see that the BaseReg = R2. But the t2LEApcrelJT instruction
> defines R3, not R2. But this is should be fine, because the t2ADDrs
> instruction takes R3 and defines R2, which is the real base address. ****
>
> ** **
>
> So my question is why is the restriction LeaMI->getOperand(0).getReg() !=
> BaseReg there? Shouldn’t the restriction be trying to ensure that the
> register defined by t2LEApcrelJT also be the register used by the t2ADDrs
> instruction? It seems this test is being overly restrictive.****
>
> ** **
>
> Daniel****
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130729/82110030/attachment.html>