ADDE on HW that doesn't have flags?

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.

I could figure out how to create a fake flags registers, but I'd rather not have to.

Any recommendations?

Thanks,

Dan

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

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

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

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.

That said, it would be nice if ADDE/ADDC could be expanded into
code sequences. The main problem is that there seems to be no
way to generate results of type MVT::Flag (ADDC is supposed to
produce one, and ADDE consume one).

Ciao,

Duncan.

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

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.

Flags are a hack. They say "the producer and the consumer must be
sequential". That way things like the carry flag on x86 just works
out for cases like this.

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

That is really incidental to the addc/adde sequence. The flag edge in
the DAG simple makes sure the instructions are togeather so hidden
dataflow isn't clobbered.

Andrew