[llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
These opcodes have been deprecated about a year ago, but still in use in various backend.

In https://reviews.llvm.org/D47422 I would like to change the behavior of the backend to not enable the use of these opcodes by default. The opcode remains usable by any backend that wish to use them, but that should limit the situation where newer backend just use them as they are enabled by default.

This shouldn't break any out of tree backend, however, it may cause misoptimisation if the backend dev do not activate these opcodes via setOperationAction and rely on them for some of their optimizations.

I would like to gather some feedback about moving forward with that as it can impact a wide range of users.

So, feedback ?

Thanks in advance for your answers,

Amaury Séchet

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
For targets where ADDCARRY and SUBCARRY are legal, would it make sense
to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)?

Are there plans to deprecate UADDO/USUBO in favor of ADDCARRY/SUBCARRY?

-Krzysztof


On 5/30/2018 11:57 AM, Amaury Séchet via llvm-dev wrote:

> These opcodes have been deprecated about a year ago, but still in use in
> various backend.
>
> In https://reviews.llvm.org/D47422 I would like to change the behavior
> of the backend to not enable the use of these opcodes by default. The
> opcode remains usable by any backend that wish to use them, but that
> should limit the situation where newer backend just use them as they are
> enabled by default.
>
> This shouldn't break any out of tree backend, however, it may cause
> misoptimisation if the backend dev do not activate these opcodes via
> setOperationAction and rely on them for some of their optimizations.
>
> I would like to gather some feedback about moving forward with that as
> it can impact a wide range of users.
>
> So, feedback ?
>
> Thanks in advance for your answers,
>
> Amaury Séchet
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
On 5/30/2018 10:29 AM, Krzysztof Parzyszek via llvm-dev wrote:
> For targets where ADDCARRY and SUBCARRY are legal, would it make sense
> to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)?

SelectionDAG will never generate ADDC/ADDE on targets where they aren't
legal.  Targets which custom-lower ADDCARRY generally also custom-lower
UADDO; not sure what sort of expansion you're thinking of.

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
On 5/30/2018 1:16 PM, Friedman, Eli wrote:
> On 5/30/2018 10:29 AM, Krzysztof Parzyszek via llvm-dev wrote:
>> For targets where ADDCARRY and SUBCARRY are legal, would it make sense
>> to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)?
>
> SelectionDAG will never generate ADDC/ADDE on targets where they aren't
> legal.  Targets which custom-lower ADDCARRY generally also custom-lower
> UADDO; not sure what sort of expansion you're thinking of.

If ADDC/ADDE cannot ever appear, then that's ok. The expansion of a long
ADD will generate UADDO for the first addition. UADDO is unnecessary
since ADDCARRY already includes UADDO's functionality, so if target sets
UADDO to Expand, it could be replaced with ADDCARRY. Targets can handle
both manually, but why should they have to?

I was actually working on using ADDCARRY on Hexagon and I find the UADDO
generation a little annnoying.

-Krzysztof

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
On 5/30/2018 11:28 AM, Krzysztof Parzyszek wrote:

> On 5/30/2018 1:16 PM, Friedman, Eli wrote:
>> On 5/30/2018 10:29 AM, Krzysztof Parzyszek via llvm-dev wrote:
>>> For targets where ADDCARRY and SUBCARRY are legal, would it make
>>> sense to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)?
>>
>> SelectionDAG will never generate ADDC/ADDE on targets where they
>> aren't legal.  Targets which custom-lower ADDCARRY generally also
>> custom-lower UADDO; not sure what sort of expansion you're thinking of.
>
> If ADDC/ADDE cannot ever appear, then that's ok. The expansion of a
> long ADD will generate UADDO for the first addition. UADDO is
> unnecessary since ADDCARRY already includes UADDO's functionality, so
> if target sets UADDO to Expand, it could be replaced with ADDCARRY.
> Targets can handle both manually, but why should they have to?
>
> I was actually working on using ADDCARRY on Hexagon and I find the
> UADDO generation a little annnoying.
>

If the expansion of UADDO would be useful, patch welcome, I guess. (It
isn't useful on architectures like ARM; we have to special-case UADDO
anyway to generate "adds" instead of "adcs".)

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
On 5/30/2018 2:10 PM, Friedman, Eli wrote:
>
> If the expansion of UADDO would be useful, patch welcome, I guess. (It
> isn't useful on architectures like ARM; we have to special-case UADDO
> anyway to generate "adds" instead of "adcs".)

https://reviews.llvm.org/D47559

-Krzysztof

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
In reply to this post by Bruce Hoult via llvm-dev
On 2018-05-30 16:57, Amaury Séchet via llvm-dev wrote:

> These opcodes have been deprecated about a year ago, but still in use
> in various backend.
>
> In https://reviews.llvm.org/D47422 I would like to change the behavior
> of the backend to not enable the use of these opcodes by default. The
> opcode remains usable by any backend that wish to use them, but that
> should limit the situation where newer backend just use them as they
> are enabled by default.
>
> This shouldn't break any out of tree backend, however, it may cause
> misoptimisation if the backend dev do not activate these opcodes via
> setOperationAction and rely on them for some of their optimizations.

Thanks for heads up, this will impact the OR1K backend.

Is there any guidance for migrating to U*O/*CARRY?

--
whitequark
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
On 5/31/2018 11:28 AM, whitequark via llvm-dev wrote:

> On 2018-05-30 16:57, Amaury Séchet via llvm-dev wrote:
>> These opcodes have been deprecated about a year ago, but still in use
>> in various backend.
>>
>> In https://reviews.llvm.org/D47422 I would like to change the behavior
>> of the backend to not enable the use of these opcodes by default. The
>> opcode remains usable by any backend that wish to use them, but that
>> should limit the situation where newer backend just use them as they
>> are enabled by default.
>>
>> This shouldn't break any out of tree backend, however, it may cause
>> misoptimisation if the backend dev do not activate these opcodes via
>> setOperationAction and rely on them for some of their optimizations.
>
> Thanks for heads up, this will impact the OR1K backend.
>
> Is there any guidance for migrating to U*O/*CARRY?
>
If your target has a dedicated flags/carry register (x86/ARM/etc.), see
https://reviews.llvm.org/D35192 for a description of how to add the
necessary conversions to get efficient lowering.  Otherwise, the correct
lowering should be obvious; see https://reviews.llvm.org/D47559 .

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev


2018-05-31 21:37 GMT+02:00 Friedman, Eli via llvm-dev <[hidden email]>:
On 5/31/2018 11:28 AM, whitequark via llvm-dev wrote:
On 2018-05-30 16:57, Amaury Séchet via llvm-dev wrote:
These opcodes have been deprecated about a year ago, but still in use
in various backend.

In https://reviews.llvm.org/D47422 I would like to change the behavior
of the backend to not enable the use of these opcodes by default. The
opcode remains usable by any backend that wish to use them, but that
should limit the situation where newer backend just use them as they
are enabled by default.

This shouldn't break any out of tree backend, however, it may cause
misoptimisation if the backend dev do not activate these opcodes via
setOperationAction and rely on them for some of their optimizations.

Thanks for heads up, this will impact the OR1K backend.

Is there any guidance for migrating to U*O/*CARRY?

If your target has a dedicated flags/carry register (x86/ARM/etc.), see https://reviews.llvm.org/D35192 for a description of how to add the necessary conversions to get efficient lowering.  Otherwise, the correct lowering should be obvious; see https://reviews.llvm.org/D47559 .

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

These guidelines are good. The X86 backend does something very similar.

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
In reply to this post by Bruce Hoult via llvm-dev
I meant this for llvm-dev...

On 6/4/2018 10:00 AM, Krzysztof Parzyszek via llvm-commits wrote:

> UADDO is equivalent to ADDCARRY(_, _, 0), and similarly for USUBO. There
> is no need for both.
>
> -Krzysztof
>
>
> On 6/1/2018 7:39 AM, Amaury Séchet wrote:
>> Hi,
>>
>> UADDO and USOB are not goign away or at least there are no plan for
>> them to go away at the moment. If your target is able to materialize
>> ADDCARRY/SUBCARRY, then it straightforward to materialize UADDO/USUBO.
>>
>> If the target supports UADDO/ADDCARRY, it is already used instead of
>> ADDC/ADDE.
>>
>> 2018-05-30 19:29 GMT+02:00 Krzysztof Parzyszek via llvm-dev
>> <[hidden email] <mailto:[hidden email]>>:
>>
>>     For targets where ADDCARRY and SUBCARRY are legal, would it make
>>     sense to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for
>> sub)?
>>
>>     Are there plans to deprecate UADDO/USUBO in favor of
>> ADDCARRY/SUBCARRY?
>>
>>     -Krzysztof
>>
>>
>>
>>     On 5/30/2018 11:57 AM, Amaury Séchet via llvm-dev wrote:
>>
>>         These opcodes have been deprecated about a year ago, but still
>>         in use in various backend.
>>
>>         In https://reviews.llvm.org/D47422
>>         <https://reviews.llvm.org/D47422> I would like to change the
>>         behavior of the backend to not enable the use of these opcodes
>>         by default. The opcode remains usable by any backend that wish
>>         to use them, but that should limit the situation where newer
>>         backend just use them as they are enabled by default.
>>
>>         This shouldn't break any out of tree backend, however, it may
>>         cause misoptimisation if the backend dev do not activate these
>>         opcodes via setOperationAction and rely on them for some of
>>         their optimizations.
>>
>>         I would like to gather some feedback about moving forward with
>>         that as it can impact a wide range of users.
>>
>>         So, feedback ?
>>
>>         Thanks in advance for your answers,
>>
>>         Amaury Séchet
>>
>>
>>         _______________________________________________
>>         LLVM Developers mailing list
>>         [hidden email] <mailto:[hidden email]>
>>         http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>         <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>>
>>     --     Qualcomm Innovation Center, Inc. is a member of Code Aurora
>> Forum,
>>     hosted by The Linux Foundation
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>>
>

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
In reply to this post by Bruce Hoult via llvm-dev
On 5/30/2018 2:10 PM, Friedman, Eli wrote:
> If the expansion of UADDO would be useful, patch welcome, I guess. (It
> isn't useful on architectures like ARM; we have to special-case UADDO
> anyway to generate "adds" instead of "adcs".)

Wouldn't that be the same as special-casing ADDCARRY with zero carry-in?

-Krzysztof

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Deprecating ADDC/ADDE/SUBC/SUBE

Bruce Hoult via llvm-dev
On 6/4/2018 8:05 AM, Krzysztof Parzyszek wrote:
> On 5/30/2018 2:10 PM, Friedman, Eli wrote:
>> If the expansion of UADDO would be useful, patch welcome, I guess.
>> (It isn't useful on architectures like ARM; we have to special-case
>> UADDO anyway to generate "adds" instead of "adcs".)
>
> Wouldn't that be the same as special-casing ADDCARRY with zero carry-in?
>

Yes.

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev