Hi guys, This patch generalizes recently commited addcarryx-intrinsic so that it could be generated either via ADCX or common ADC instruction. ADX-* tests are ok, bootstrap is passed. Is it ok for trunk?
Changelog entry:
2012-08-09 Michael Zolotukhin <michael.v.zolotuk...@intel.com>
* config/i386/adxintrin.h: Remove guarding __ADX__ check.
* config/i386/x86intrin.h: Likewise.
* config/i386/i386.c (ix86_init_mmx_sse_builtins): Remove
OPTION_MASK_ISA_ADX from needed options for
__builtin_ia32_addcarryx_u32 and __builtin_ia32_addcarryx_u64.
(ix86_expand_builtin): Use add<mode>3_carry in expanding of
IX86_BUILTIN_ADDCARRYX32 and IX86_BUILTIN_ADDCARRYX64.
testsuite/Changelog entry:
2012-08-09 Michael Zolotukhin <michael.v.zolotuk...@intel.com>
* gcc.target/i386/adx-addxcarry32-3.c: New.
* gcc.target/i386/adx-addxcarry64-3.c: New.
Thanks, Michael
On 1 August 2012 20:37, Kirill Yukhin <kirill.yuk...@gmail.com> wrote:
> Hi Richard,
>
>> Frankly I don't understand the point of these instructions
>> being added to the ISA at all. I would have understood an
>> add-with-carry that did *not* modify the flags at all, but
>> two separate ones that modify C and O separately is just
>> downright strange.
> If there is only one carry in flight, they all are equivalent although
> ADOX is a little less useful in loops.
> If there are two carries in flight, that’s where the new instructions
> show their benefit, since they allow accumulation without destroying
> each other (see next comment).
> For any number of carries beyond two, you have to start saving
> restoring carry bits and it degenerates to the first case for some of
> them.
>
>> But to the point: I don't understand the point of having
>> this as a builtin. Is the code generated by this builtin
>> any better than plain C?
> I think this is just like a practice to introduce new intrinsics for new
> insns.
> I doubt, that we may generate such things automatically:
> c1 = 0;
> c2 = 0;
> c1 = _adcx64( & res[i], src[i], src2[i], c1);
> c1 = _adcx64( & res[i+1], src[i+1], src2[i+1], c1);
> c2 = _adcx64( & res[i], src[i], src2[i], c2);
> c2 = _adcx64( & res[i+1], src[i+1], src2[i+1], c2);
>
>> And if you're going to have the builtin, why is this restricted
>> to adx anyway? You obviously can produce the same results with
>> the good old fashioned adc instruction as well.
> We have one intrinsic for both ADCX/ADOX. So, we just picked up first
> one to use when exanding the built-in
>
>> Which begs the question of why you've got a separate pattern
>> for the adx anyway. If the insn is so much better, it ought to
>> be used in the same pattern we use for adc now.
> I believe, we may introduce global variant of ADCX, which may be
> expanded into either of ADC/ADCX/ADOX on x86 and into analogs
> on the other ports.
>
> K
--
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.
bdw-adx-5.gcc.patch
Description: Binary data
