thr3ads.net - llvm dev - [LLVMdev] Question on optimizeThumb2JumpTables [Jul 2013]

If this information is useful, please help other people find it:
Share via:

Daniel Stewart

2013-Jul-23 13:55 UTC

[LLVMdev] Question on optimizeThumb2JumpTables

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 registerused 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130723/4f1367c0/attachment.html>

Chad Rosier

2013-Jul-29 13:50 UTC

head link

[LLVMdev] Question on optimizeThumb2JumpTables

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>

Jakob Stoklund Olesen

2013-Jul-29 16:25 UTC

head link

[LLVMdev] Question on optimizeThumb2JumpTables

On Jul 29, 2013, at 6:50 AM, Chad Rosier <chad.rosier at gmail.com> wrote:
> Hi Jakob,
> You're the unfortunate soul who last touched the constant island pass,
right?  Do you happen to have any insight for Daniel?
Sorry, no. I don't remember working with that particular bit of code. You
could try digging through the commit logs.

Thanks,
/jakob


> 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/b2f895ea/attachment.html>

Seemingly Similar Threads

Search for more possibly parallel threads

llvm dev - Jul 2013 - [LLVMdev] Question on optimizeThumb2JumpTables

[LLVMdev] Question on optimizeThumb2JumpTables

[LLVMdev] Question on optimizeThumb2JumpTables

[LLVMdev] Question on optimizeThumb2JumpTables

Seemingly Similar Threads