[llvm] r186364 - PEI: Support for non-zero SPAdj at beginning of a basic block.

[Francois Pichet]

On Fri, Oct 25, 2013 at 7:24 PM, Manman Ren <manman.ren at gmail.com> wrote:

>
>
>
> On Wed, Oct 23, 2013 at 10:13 AM, Francois Pichet <pichet2000 at gmail.com>wrote:
>
>> Hi, this change break the Opus DSP out of tree backend. (we just updated
>> to trunk)
>>
>> The reason is that the Opus DSP backend end up creating a new  BasicBlock
>> in eliminateCallFramePseudoInstr (called by replaceFrameIndices)
>> Your change assume that the no new BBs are created in replaceFrameIndices
>>
>> Because:
>>   SmallVector<int, 8> SPState;
>>   SPState.resize(Fn.getNumBlockIDs());
>>
>> SPState won't change size.
>>
>> Is it reasonable to change your loop to be able to deal with new
>> BasicBlock created during replaceFrameIndices. It might not be I haven't
>> really analyzed everything but it is working if I revert this specific
>> commit.
>>
>
> Before the commit, we use
>    for (MachineFunction::iterator BB = Fn.begin(), E = Fn.end(); BB != E;
> ++BB) {
>      int SPAdj = 0;
>      replaceFrameIndices(BB, Fn, SPAdj);
>    }
>
> I don't think it will work if replaceFrameIndices can create new BBs.
> Let's figure out the issue first, then talk about what to do.
>
>
>
It was working because the iterator will use ++BB to get the the next
BasicBlock and the new BB were always added after the current BB.

Now I realize that creating a new BB in eliminateCallFramePseudoInstr was
not ideal.

What we are trying to do is creating a new BB after each function call;
that new BB is used to get the return address that we assign to a register
before calling the function. the called function will then jump using that
register to return.

I guess i'll move that logic elsewhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131026/c28a90b4/attachment.html>