[llvm] r186364 - PEI: Support for non-zero SPAdj at beginning of a basic block.
Francois Pichet
pichet2000 at gmail.com
Sat Oct 26 15:21:51 PDT 2013
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>
More information about the llvm-commits
mailing list