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

[Krzysztof Parzyszek 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 
>> <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