llvm dev - Oct 2008 - [LLVMdev] ADDE on HW that doesn't have flags?

Thanks - that solves both problems.

In the future, HW may have built in ADDE support, but will likely  
still not have flags - it'll just read 3 registers and write two.

Any thoughts there?

Thanks,

Dan

On Oct 27, 2008, at 12:07 PM, Andrew Lenharth wrote:
> On Mon, Oct 27, 2008 at 10:11 AM, Daniel M Gessel <gessel at
apple.com>
> wrote:
>> The language I'm targeting doesn't have flags; I'd like to
implement
>> ADDE as a macro or psuedo-instruction that takes 3 parameters and
>> returns 2.
>>
>> In my InstrInfo.td file, tablegen complains if I try to define
>> multiple return values; adde is defined in TargetSelectionDAG.td to  
>> be
>> a binary op that takes an extra flag in and sends an extra flag out.
>>
>> I tried to custom lower ADDE (by calling setOperationAction with
>> ISD::ADDE) but it didn't seem to register and still bailed when  
>> trying
>> to expand adde, instead of calling my LowerOperation.
>
> ADDE should only be generated if you specify ADDC as legal.  If ADDC
> is illegal, larger integer arith will be lowered to add and cmp
> sequences rather than addc adde sequences.
>
> Andrew
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Mon, Oct 27, 2008 at 11:15 AM, Daniel M Gessel <gessel at apple.com>
wrote:
> Thanks - that solves both problems.
>
> In the future, HW may have built in ADDE support, but will likely
> still not have flags - it'll just read 3 registers and write two.
>
> Any thoughts there?
Yes.  What I think should happen is flags need to be less of a hack.
There are two cases, instruction ordering/binding uses, and hidden
dataflow uses.  Modeling flags as registers on processors that have
flags is not something I am qualified to speak on (though I suspect it
would put an unnecessary compuational burdon on the scheduler and RA,
esp on x86), but seperating control and dataflow flags so that an arch
can say dataflow flags are always registers would let legalize know
that addc was <int, dataflowflag> and that on the arch dataflowflag
=register, so it could handle fixing up the types to <int, bool>.
Right now, addc can't be legalized locally to add and cmp because the
result of legalization needs to be the same type as before.

Andrew

Thanks very much for your help.

I didn't quite understand how adde really uses flags in, say x86 or  
any of the other architectures I looked at.

It seemed to declare it used EFLAGS, but little else: like how would  
you feed a zero in for the carry.

Or I suppose you would have to start such a sequence off with an addc,  
and I happened to hit the adde (and it bailed) first (because the addc  
would be further from the root of the DAG)?

Dan


On Oct 27, 2008, at 12:30 PM, Andrew Lenharth wrote:
> On Mon, Oct 27, 2008 at 11:15 AM, Daniel M Gessel <gessel at
apple.com>
> wrote:
>> Thanks - that solves both problems.
>>
>> In the future, HW may have built in ADDE support, but will likely
>> still not have flags - it'll just read 3 registers and write two.
>>
>> Any thoughts there?
>
> Yes.  What I think should happen is flags need to be less of a hack.
> There are two cases, instruction ordering/binding uses, and hidden
> dataflow uses.  Modeling flags as registers on processors that have
> flags is not something I am qualified to speak on (though I suspect it
> would put an unnecessary compuational burdon on the scheduler and RA,
> esp on x86), but seperating control and dataflow flags so that an arch
> can say dataflow flags are always registers would let legalize know
> that addc was <int, dataflowflag> and that on the arch dataflowflag
=> register, so it could handle fixing up the types to <int, bool>.
> Right now, addc can't be legalized locally to add and cmp because the
> result of legalization needs to be the same type as before.
>
> Andrew
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev