llvm dev - Jun 2017 - Question about ISD::SUBCARRY

Dear all,

a couple of new generic DAG nodes ISD::ADCARRY and ISD::SUBCARRY were recently
introduced in https://reviews.llvm.org/D29872

These nodes have three inputs and two outputs, the second output being the
"carry". I understand that carry is well defined for ADDCARRY but my
question is about SUBCARRY.

Some architectures set the "carry" of a "x - y" subtraction
is set when x < y (e.g x86, "borrow") and some others set it when x
>= y (e.g. ARM). Does the ISD::SUBCARRY picks one interpretation (and uses it
for combiners on top of this node) or leaves the interpretation to the target.

Maybe my whole question does not make sense and even if only one interpretation
is chosen this does not impact the target?

Thank you very much,
Roger

That's an excellent question. :)

I'd say it should _probably_ be defined as having the same boolean value as
the hardware's carry-flag, and there should be a TargetLowering function
which describes the semantics upon subtract.

On Tue, Jun 27, 2017 at 4:53 AM, Roger Ferrer Ibanez via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Dear all,
>
> a couple of new generic DAG nodes ISD::ADCARRY and ISD::SUBCARRY were
> recently introduced in https://reviews.llvm.org/D29872
>
> These nodes have three inputs and two outputs, the second output being the
> "carry". I understand that carry is well defined for ADDCARRY but
my
> question is about SUBCARRY.
>
> Some architectures set the "carry" of a "x - y"
subtraction is set when x
> < y (e.g x86, "borrow") and some others set it when x >= y
(e.g. ARM). Does
> the ISD::SUBCARRY picks one interpretation (and uses it for combiners on
> top of this node) or leaves the interpretation to the target.
>
> Maybe my whole question does not make sense and even if only one
> interpretation is chosen this does not impact the target?
>
> Thank you very much,
> Roger
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/f36fde7b/attachment-0001.html>

Hi James,

thanks for your answer.

Your suggestion looks sensible to me, then I understand that a combiner like the
following one (DAGCombiner::visitSUBCARRY)

  http://www.llvm.org/doxygen/DAGCombiner_8cpp_source.html#l02498

that assumes that “subcarry x, y, 0” can be simplified as “usubo x, y” should be
parameterized using TargetLowering, as this assumes that the third input of
subcarry is a borrow (e.g. x86) rather than a “carry” (e.g. ARM).

Does this make sense? Maybe I’m mixing things here.

( For context: I’m trying to establish if I can avoid adding ARM specific
combiners in https://reviews.llvm.org/D34515 and use the generic ones instead. )

Kind regards,
Roger


From: James Y Knight [mailto:jyknight at google.com]
Sent: 27 June 2017 17:00
To: Roger Ferrer Ibanez
Cc: llvm-dev; nd
Subject: Re: [llvm-dev] Question about ISD::SUBCARRY

That's an excellent question. :)

I'd say it should _probably_ be defined as having the same boolean value as
the hardware's carry-flag, and there should be a TargetLowering function
which describes the semantics upon subtract.

On Tue, Jun 27, 2017 at 4:53 AM, Roger Ferrer Ibanez via llvm-dev <llvm-dev
at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Dear all,

a couple of new generic DAG nodes ISD::ADCARRY and ISD::SUBCARRY were recently
introduced in https://reviews.llvm.org/D29872

These nodes have three inputs and two outputs, the second output being the
"carry". I understand that carry is well defined for ADDCARRY but my
question is about SUBCARRY.

Some architectures set the "carry" of a "x - y" subtraction
is set when x < y (e.g x86, "borrow") and some others set it when x
>= y (e.g. ARM). Does the ISD::SUBCARRY picks one interpretation (and uses it
for combiners on top of this node) or leaves the interpretation to the target.

Maybe my whole question does not make sense and even if only one interpretation
is chosen this does not impact the target?

Thank you very much,
Roger
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170628/b390b657/attachment.html>