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

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 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

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