This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Intrinsics for ADCX
- From: Kirill Yukhin <kirill dot yukhin at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Michael Zolotukhin <michael dot v dot zolotukhin at gmail dot com>, Uros Bizjak <ubizjak at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, gcc-patches at gcc dot gnu dot org, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Wed, 1 Aug 2012 20:37:07 +0400
- Subject: Re: [PATCH] Intrinsics for ADCX
- References: <CANtU079t0X=e6VrFxVBLYi9Nda+KzUH8EVow=8QsT8RBFmsJHw@mail.gmail.com> <501802A7.email@example.com>
> 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
> 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.