[LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc

[hilbert Wang]

Tim and all,

thanks to Tim, now i started  to understand the basic theory.

my understanding of the problem was as follows.
1) 16-bit ADD/SUB, has four loads: ld a,ld a+1, ld b,ld b+1. they were the
operands of  the said TF node
2) ADDC  happends after  ld a,lb b, so  the TF node  happens before ADDC
3) ADDE  happends after ADDC
4) ADDE modifies a+1, so it must happen before the subsequent STORE. so the
input chain update makes sense.

the problem here was. that the TF happends before ADDC is not wrong, but ld
a+1, ld b+1 can happen after ADDC.

if we split the TF node into two:
TF1:ld a,ld b
TF2: ld a_1,ld b+1
 then the problem should be gone.

Cheers.

hilbert



On Mon, Apr 28, 2014 at 2:03 PM, Tim Northover <t.p.northover at gmail.com>wrote:

> Hi Hilbert,
>
> > i  had not understood the purpose of a TF node.
> > my understanding was, the operands  were  not loaded together in one
> node. they were loaded separately.
>
> The loads happen separately, but the TokenFactor node says that
> whichever order they do happen in, they *both* have to be before
> whatever comes next (the user of the TokenFactor). It's there to
> constrain LLVM's scheduling.
>
> > 4) replace any operands of the TF Node with ADDE did not make sense.
>
> It does to me. Before we were saying that the load of "a+1" had to
> happen before X (which might be, for example, a subsequent write to
> the 16-bit variable "a"). If that load has been folded into an ADDE,
> then that ADDE has to happen before X too.
>
> > 3)the DAG after ADDC was seleced:
>
> Now that's one thing I don't understand. The ADDC should be "above"
> the ADDE in the DAG since the ADDE depends on the output of the ADDC.
> How did it get selected first?
>
> The DAGs you posted aren't really that useful I'm afraid: deciphering
> the text layout is a massive pain in the neck; the machine nodes are
> given purely by number (I have no idea what they are); your first dump
> appears to be from half way through ISel (which *is* interesting), but
> I'd mostly like before & after to begin with.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140429/d750ce5f/attachment.html>