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

[Krzysztof Parzyszek via llvm-commits]

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