llvm dev - May 2018 - Deprecating ADDC/ADDE/SUBC/SUBE

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180530/7ee76022/attachment.html>

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
> llvm-dev at lists.llvm.org
> 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

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

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

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

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 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>:
>>
>>     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
>>         llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>         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
>>     llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>     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