[LLVMdev] [llvmdev] Whole function SelectionDAG

[Zhongxing Xu]

I have another idea: let the BasicBlockSDNode points to the last node in its
predecessor blocks. But this will introduce cycles into the selection DAG,
making it not a DAG anymore.

So what's the impact of a non-DAG on the existing DAG legalizers and
combiner?

On Wed, Jun 9, 2010 at 9:33 AM, Zhongxing Xu <xuzhongxing at gmail.com> wrote:

> At first I'll try the simplest strategy: put the instruction in the machine
> BB corresponding to the LLVM BB where it comes from.
>
> To implement this, I plan to add an operand to non-passive node which
> points to the BasicBlockSDNode which the node belongs to.
>
> Another idea is to use a side map to map each node to its block. But I
> guess it's difficult to keep the map consistent when transforming the DAG.
>
>
> On Wed, Jun 9, 2010 at 1:39 AM, Dan Gohman <gohman at apple.com> wrote:
>
>> The first question is code placement.  How is the compiler going to decide
>> which block (or blocks) to emit an instruction in?  The answer to that will
>> help determine how control relationships should be represented.
>>
>> Dan
>>
>>
>> On Jun 7, 2010, at 11:56 PM, Zhongxing Xu <xuzhongxing at gmail.com> wrote:
>>
>>  I am trying to build a DAG for a whole function. The first problem I met
>>> is to assign a user for the last instruction of each basic block, be it
>>> BRCOND or other node. There is no natural user for such nodes. Without user,
>>> it will be removed in later phases. My idea is to use it as chain for nodes
>>> in the next basic block. Is this reasonable?
>>>
>>> -Zhongxing Xu
>>> _______________________________________________
>>> 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/20100611/266f0821/attachment.html>