subject:"\[PATCH\] Intrinsics for ADCX"

Re: [PATCH] Intrinsics for ADCX

2012-08-15 Thread Kirill Yukhin

Hi,
There's white paper [1] available, which explains usage of  MULX/ADCX/ADOX

[1] - http://download.intel.com/embedded/processor/whitepaper/327831.pdf

Thanks, K

Re: [PATCH] Intrinsics for ADCX

2012-08-09 Thread Michael Zolotukhin

Thanks!

On 9 August 2012 18:36, Kirill Yukhin  wrote:
>>
>> Ok.
>
> Checked in:
> http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00231.html
>
> Thanks, K


-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.

Re: [PATCH] Intrinsics for ADCX

2012-08-09 Thread Kirill Yukhin

>
> Ok.

Checked in:
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00231.html

Thanks, K

Re: [PATCH] Intrinsics for ADCX

2012-08-09 Thread Richard Henderson

On 08/09/2012 05:21 AM, Michael Zolotukhin wrote:
> Changelog entry:
> 2012-08-09  Michael Zolotukhin  
> 
> * 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 add3_carry in expanding of
> IX86_BUILTIN_ADDCARRYX32 and IX86_BUILTIN_ADDCARRYX64.
> 
> testsuite/Changelog entry:
> 2012-08-09  Michael Zolotukhin  
> 
> * gcc.target/i386/adx-addxcarry32-3.c: New.
> * gcc.target/i386/adx-addxcarry64-3.c: New.

Ok.


r~

Re: [PATCH] Intrinsics for ADCX

2012-08-09 Thread Michael Zolotukhin

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  

* 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 add3_carry in expanding of
IX86_BUILTIN_ADDCARRYX32 and IX86_BUILTIN_ADDCARRYX64.

testsuite/Changelog entry:
2012-08-09  Michael Zolotukhin  

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

Re: [PATCH] Intrinsics for ADCX

2012-08-08 Thread Kirill Yukhin

> Here is the patch with some obvious fixes. If there are no objections,
> could anyone please check it in?
Done:
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00203.html

Thanks, K

Re: [PATCH] Intrinsics for ADCX

2012-08-07 Thread Michael Zolotukhin

Hi,
Here is the patch with some obvious fixes. If there are no objections,
could anyone please check it in?

Changelog entry:
2012-08-08 Michael Zolotukhin 

* common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
(OPTION_MASK_ISA_ADX_UNSET): Likewise.
(ix86_handle_option): Handle madx option.
* config.gcc (i[34567]86-*-*): Add adxintrin.h.
(x86_64-*-*): Likewise.
* config/i386/adxintrin.h: New header.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect ADCX/ADOX
support.
* config/i386/i386-builtin-types.def
(UCHAR_FTYPE_UCHAR_UINT_UINT_PUNSIGNED): New function type.
(UCHAR_FTYPE_UCHAR_ULONGLONG_ULONGLONG_PULONGLONG): Likewise.
* config/i386/i386-c.c: Define __ADX__ if needed.
* config/i386/i386.c (ix86_target_string): Define -madx option.
(PTA_ADX): New.
(ix86_option_override_internal): Handle new option.
(ix86_valid_target_attribute_inner_p): Add OPT_madx.
(ix86_builtins): Add IX86_BUILTIN_ADDCARRYX32,
IX86_BUILTIN_ADDCARRYX64.
(ix86_init_mmx_sse_builtins): Define corresponding built-ins.
(ix86_expand_builtin): Handle these built-ins.
(ix86_expand_args_builtin): Handle new function types.
* config/i386/i386.h (TARGET_ADX): New.
* config/i386/i386.md (adcx3): New define_insn.
* config/i386/i386.opt (madx): New.
* config/i386/x86intrin.h: Include adxintrin.h.

testsuite/Changelog entry:
2012-08-08 Michael Zolotukhin 

* gcc.target/i386/adx-addcarryx32-1.c: New.
* gcc.target/i386/adx-addcarryx32-2.c: New.
* gcc.target/i386/adx-addcarryx64-1.c: New.
* gcc.target/i386/adx-addcarryx64-2.c: New.
* gcc.target/i386/adx-check.h: New.
* gcc.target/i386/i386.exp (check_effective_target_adx): New.
* gcc.target/i386/sse-12.c: Add -madx.
* gcc.target/i386/sse-13.c: Ditto.
* gcc.target/i386/sse-14.c: Ditto.
* gcc.target/i386/sse-22.c: Ditto.
* gcc.target/i386/sse-23.c: Ditto.
* g++.dg/other/i386-2.C: Ditto.
* g++.dg/other/i386-3.C: Ditto.


On 3 August 2012 17:51, Uros Bizjak  wrote:
> On Fri, Aug 3, 2012 at 3:24 PM, Michael Zolotukhin
>  wrote:
>> Hi,
>> I made a new version of the patch, where I tried to take into account
>> Uros' remarks - is it ok for trunk?
>>
>> Bootstrap and new tests are passing, testing is in progress.
>>
>> Changelog entry:
>> 2012-08-03 Michael Zolotukhin 
>>
>> * common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
>> (OPTION_MASK_ISA_ADX_UNSET): Likewise.
>> (ix86_handle_option): Handle madx option.
>> * config.gcc (i[34567]86-*-*): Add adxintrin.h.
>> (x86_64-*-*): Likewise.
>> * config/i386/adxintrin.h: New header.
>> * config/i386/driver-i386.c (host_detect_local_cpu): Detect ADCX/ADOX
>> support.
>> * config/i386/i386-builtin-types.def
>> (UCHAR_FTYPE_UCHAR_UINT_UINT_PINT): New function type.
>> (UCHAR_FTYPE_UCHAR_ULONGLONG_ULONGLONG_PINT): Likewise.
>> * config/i386/i386-c.c: Define __ADX__ if needed.
>> * config/i386/i386.c (ix86_target_string): Define -madx option.
>> (PTA_ADX): New.
>> (ix86_option_override_internal): Handle new option.
>> (ix86_valid_target_attribute_inner_p): Add OPT_madx.
>> (ix86_builtins): Add IX86_BUILTIN_ADDCARRYX32,
>> IX86_BUILTIN_ADDCARRYX64.
>> (ix86_init_mmx_sse_builtins): Define corresponding built-ins.
>> (ix86_expand_builtin): Handle these built-ins.
>> (ix86_expand_args_builtin): Handle new function types.
>> * config/i386/i386.h (TARGET_ADX): New.
>> * config/i386/i386.md (adcx3): New define_insn.
>> * config/i386/i386.opt (madx): New.
>> * config/i386/x86intrin.h: Include adxintrin.h.
>>
>> testsuite/Changelog entry:
>> 2012-08-03 Michael Zolotukhin 
>>
>> * gcc.target/i386/adx-addcarryx32-1.c: New.
>> * gcc.target/i386/adx-addcarryx32-2.c: New.
>> * gcc.target/i386/adx-addcarryx64-1.c: New.
>> * gcc.target/i386/adx-addcarryx64-2.c: New.
>> * gcc.target/i386/adx-check.h: New.
>> * gcc.target/i386/i386.exp (check_effective_target_adx): New.
>> * gcc.target/i386/sse-12.c: Add -madx.
>> * gcc.target/i386/sse-13.c: Ditto.
>> * gcc.target/i386/sse-14.c: Ditto.
>> * gcc.target/i386/sse-22.c: Ditto.
>> * gcc.target/i386/sse-23.c: Ditto.
>> * g++.dg/other/i386-2.C: Ditto.
>> * g++.dg/other/i386-3.C: Ditto.
>
> Just change this line:
>
> +  op4 = gen_rtx_REG (CCmode, FLAGS_REG);
>
> back to CCCmode.
>
> OK with this change.
>
> Thanks,
> Uros.



-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.


bdw-adx-4.gcc.patch
Description: Binary data

Re: [PATCH] Intrinsics for ADCX

2012-08-03 Thread Michael Zolotukhin

Thanks!

On 3 August 2012 17:51, Uros Bizjak  wrote:
> On Fri, Aug 3, 2012 at 3:24 PM, Michael Zolotukhin
>  wrote:
>> Hi,
>> I made a new version of the patch, where I tried to take into account
>> Uros' remarks - is it ok for trunk?
>>
>> Bootstrap and new tests are passing, testing is in progress.
>>
>> Changelog entry:
>> 2012-08-03 Michael Zolotukhin 
>>
>> * common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
>> (OPTION_MASK_ISA_ADX_UNSET): Likewise.
>> (ix86_handle_option): Handle madx option.
>> * config.gcc (i[34567]86-*-*): Add adxintrin.h.
>> (x86_64-*-*): Likewise.
>> * config/i386/adxintrin.h: New header.
>> * config/i386/driver-i386.c (host_detect_local_cpu): Detect ADCX/ADOX
>> support.
>> * config/i386/i386-builtin-types.def
>> (UCHAR_FTYPE_UCHAR_UINT_UINT_PINT): New function type.
>> (UCHAR_FTYPE_UCHAR_ULONGLONG_ULONGLONG_PINT): Likewise.
>> * config/i386/i386-c.c: Define __ADX__ if needed.
>> * config/i386/i386.c (ix86_target_string): Define -madx option.
>> (PTA_ADX): New.
>> (ix86_option_override_internal): Handle new option.
>> (ix86_valid_target_attribute_inner_p): Add OPT_madx.
>> (ix86_builtins): Add IX86_BUILTIN_ADDCARRYX32,
>> IX86_BUILTIN_ADDCARRYX64.
>> (ix86_init_mmx_sse_builtins): Define corresponding built-ins.
>> (ix86_expand_builtin): Handle these built-ins.
>> (ix86_expand_args_builtin): Handle new function types.
>> * config/i386/i386.h (TARGET_ADX): New.
>> * config/i386/i386.md (adcx3): New define_insn.
>> * config/i386/i386.opt (madx): New.
>> * config/i386/x86intrin.h: Include adxintrin.h.
>>
>> testsuite/Changelog entry:
>> 2012-08-03 Michael Zolotukhin 
>>
>> * gcc.target/i386/adx-addcarryx32-1.c: New.
>> * gcc.target/i386/adx-addcarryx32-2.c: New.
>> * gcc.target/i386/adx-addcarryx64-1.c: New.
>> * gcc.target/i386/adx-addcarryx64-2.c: New.
>> * gcc.target/i386/adx-check.h: New.
>> * gcc.target/i386/i386.exp (check_effective_target_adx): New.
>> * gcc.target/i386/sse-12.c: Add -madx.
>> * gcc.target/i386/sse-13.c: Ditto.
>> * gcc.target/i386/sse-14.c: Ditto.
>> * gcc.target/i386/sse-22.c: Ditto.
>> * gcc.target/i386/sse-23.c: Ditto.
>> * g++.dg/other/i386-2.C: Ditto.
>> * g++.dg/other/i386-3.C: Ditto.
>
> Just change this line:
>
> +  op4 = gen_rtx_REG (CCmode, FLAGS_REG);
>
> back to CCCmode.
>
> OK with this change.
>
> Thanks,
> Uros.



-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.

Re: [PATCH] Intrinsics for ADCX

2012-08-03 Thread Uros Bizjak

On Fri, Aug 3, 2012 at 3:24 PM, Michael Zolotukhin
 wrote:
> Hi,
> I made a new version of the patch, where I tried to take into account
> Uros' remarks - is it ok for trunk?
>
> Bootstrap and new tests are passing, testing is in progress.
>
> Changelog entry:
> 2012-08-03 Michael Zolotukhin 
>
> * common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
> (OPTION_MASK_ISA_ADX_UNSET): Likewise.
> (ix86_handle_option): Handle madx option.
> * config.gcc (i[34567]86-*-*): Add adxintrin.h.
> (x86_64-*-*): Likewise.
> * config/i386/adxintrin.h: New header.
> * config/i386/driver-i386.c (host_detect_local_cpu): Detect ADCX/ADOX
> support.
> * config/i386/i386-builtin-types.def
> (UCHAR_FTYPE_UCHAR_UINT_UINT_PINT): New function type.
> (UCHAR_FTYPE_UCHAR_ULONGLONG_ULONGLONG_PINT): Likewise.
> * config/i386/i386-c.c: Define __ADX__ if needed.
> * config/i386/i386.c (ix86_target_string): Define -madx option.
> (PTA_ADX): New.
> (ix86_option_override_internal): Handle new option.
> (ix86_valid_target_attribute_inner_p): Add OPT_madx.
> (ix86_builtins): Add IX86_BUILTIN_ADDCARRYX32,
> IX86_BUILTIN_ADDCARRYX64.
> (ix86_init_mmx_sse_builtins): Define corresponding built-ins.
> (ix86_expand_builtin): Handle these built-ins.
> (ix86_expand_args_builtin): Handle new function types.
> * config/i386/i386.h (TARGET_ADX): New.
> * config/i386/i386.md (adcx3): New define_insn.
> * config/i386/i386.opt (madx): New.
> * config/i386/x86intrin.h: Include adxintrin.h.
>
> testsuite/Changelog entry:
> 2012-08-03 Michael Zolotukhin 
>
> * gcc.target/i386/adx-addcarryx32-1.c: New.
> * gcc.target/i386/adx-addcarryx32-2.c: New.
> * gcc.target/i386/adx-addcarryx64-1.c: New.
> * gcc.target/i386/adx-addcarryx64-2.c: New.
> * gcc.target/i386/adx-check.h: New.
> * gcc.target/i386/i386.exp (check_effective_target_adx): New.
> * gcc.target/i386/sse-12.c: Add -madx.
> * gcc.target/i386/sse-13.c: Ditto.
> * gcc.target/i386/sse-14.c: Ditto.
> * gcc.target/i386/sse-22.c: Ditto.
> * gcc.target/i386/sse-23.c: Ditto.
> * g++.dg/other/i386-2.C: Ditto.
> * g++.dg/other/i386-3.C: Ditto.

Just change this line:

+  op4 = gen_rtx_REG (CCmode, FLAGS_REG);

back to CCCmode.

OK with this change.

Thanks,
Uros.

Re: [PATCH] Intrinsics for ADCX

2012-08-03 Thread Michael Zolotukhin

Hi,
I made a new version of the patch, where I tried to take into account
Uros' remarks - is it ok for trunk?

Bootstrap and new tests are passing, testing is in progress.

Changelog entry:
2012-08-03 Michael Zolotukhin 

* common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
(OPTION_MASK_ISA_ADX_UNSET): Likewise.
(ix86_handle_option): Handle madx option.
* config.gcc (i[34567]86-*-*): Add adxintrin.h.
(x86_64-*-*): Likewise.
* config/i386/adxintrin.h: New header.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect ADCX/ADOX
support.
* config/i386/i386-builtin-types.def
(UCHAR_FTYPE_UCHAR_UINT_UINT_PINT): New function type.
(UCHAR_FTYPE_UCHAR_ULONGLONG_ULONGLONG_PINT): Likewise.
* config/i386/i386-c.c: Define __ADX__ if needed.
* config/i386/i386.c (ix86_target_string): Define -madx option.
(PTA_ADX): New.
(ix86_option_override_internal): Handle new option.
(ix86_valid_target_attribute_inner_p): Add OPT_madx.
(ix86_builtins): Add IX86_BUILTIN_ADDCARRYX32,
IX86_BUILTIN_ADDCARRYX64.
(ix86_init_mmx_sse_builtins): Define corresponding built-ins.
(ix86_expand_builtin): Handle these built-ins.
(ix86_expand_args_builtin): Handle new function types.
* config/i386/i386.h (TARGET_ADX): New.
* config/i386/i386.md (adcx3): New define_insn.
* config/i386/i386.opt (madx): New.
* config/i386/x86intrin.h: Include adxintrin.h.

testsuite/Changelog entry:
2012-08-03 Michael Zolotukhin 

* gcc.target/i386/adx-addcarryx32-1.c: New.
* gcc.target/i386/adx-addcarryx32-2.c: New.
* gcc.target/i386/adx-addcarryx64-1.c: New.
* gcc.target/i386/adx-addcarryx64-2.c: New.
* gcc.target/i386/adx-check.h: New.
* gcc.target/i386/i386.exp (check_effective_target_adx): New.
* gcc.target/i386/sse-12.c: Add -madx.
* gcc.target/i386/sse-13.c: Ditto.
* gcc.target/i386/sse-14.c: Ditto.
* gcc.target/i386/sse-22.c: Ditto.
* gcc.target/i386/sse-23.c: Ditto.
* g++.dg/other/i386-2.C: Ditto.
* g++.dg/other/i386-3.C: Ditto.

Thanks, Michael

On 1 August 2012 20:37, Kirill Yukhin  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-3.gcc.patch
Description: Binary data

Re: [PATCH] Intrinsics for ADCX

2012-08-01 Thread Kirill Yukhin

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

Re: [PATCH] Intrinsics for ADCX

2012-07-31 Thread Richard Henderson

On 2012-07-31 04:33, Michael Zolotukhin wrote:
> Here is a third part of patch, refactored by Kirill. This one adds
> _addcarryx_u[32|64]  intrinsics.

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.

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?

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.

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.

r~

Re: [PATCH] Intrinsics for ADCX

2012-07-31 Thread Uros Bizjak

On Tue, Jul 31, 2012 at 1:33 PM, Michael Zolotukhin
 wrote:
> Hi guys,
> Here is a third part of patch, refactored by Kirill. This one adds
> _addcarryx_u[32|64]  intrinsics.
>
> Is it ok?
>
> Changelog entry:
> 2012-07-31 Michael Zolotukhin 
>
> * common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
> (OPTION_MASK_ISA_ADX_UNSET): Likewise.
> (ix86_handle_option): Handle madx option.
> * config.gcc (i[34567]86-*-*): Add adxintrin.h.
> (x86_64-*-*): Likewise.
> * config/i386/adxintrin.h: New header.
> * config/i386/driver-i386.c (host_detect_local_cpu): Detect ADCX/ADOX
> support.
> * config/i386/i386-builtin-types.def
> (UCHAR_FTYPE_UCHAR_UINT_UINT_PINT): New function type.
> (UCHAR_FTYPE_UCHAR_ULONGLONG_ULONGLONG_PINT): Likewise.
> * config/i386/i386-c.c: Define __ADX__ if needed.
> * config/i386/i386.c (ix86_target_string): Define -madx option.
> (PTA_ADX): New.
> (ix86_option_override_internal): Handle new option.
> (ix86_valid_target_attribute_inner_p): Add OPT_madx.
> (ix86_builtins): Add IX86_BUILTIN_ADDCARRYX32,
> IX86_BUILTIN_ADDCARRYX64.
> (ix86_init_mmx_sse_builtins): Define corresponding built-ins.
> (ix86_expand_builtin): Handle these built-ins.
> (ix86_expand_args_builtin): Handle new function types.
> * config/i386/i386.h (TARGET_ADX): New.
> * config/i386/i386.md (adcx): New define_expand.
> (adcx_carry): New define_insn.
> * config/i386/i386.opt (madx): New.
> * config/i386/x86intrin.h: Include adxintrin.h.
>
> testsuite/Changelog entry:
> 2012-07-31 Michael Zolotukhin 
>
> * gcc.target/i386/adx-addcarryx32-1.c: New.
> * gcc.target/i386/adx-addcarryx32-2.c: New.
> * gcc.target/i386/adx-addcarryx64-1.c: New.
> * gcc.target/i386/adx-addcarryx64-2.c: New.
> * gcc.target/i386/adx-check.h: New.
> * gcc.target/i386/i386.exp (check_effective_target_adx): New.
> * gcc.target/i386/sse-12.c: Add -madx.
> * gcc.target/i386/sse-13.c: Ditto.
> * gcc.target/i386/sse-14.c: Ditto.
> * gcc.target/i386/sse-22.c: Ditto.
> * gcc.target/i386/sse-23.c: Ditto.
> * g++.dg/other/i386-2.C: Ditto.
> * g++.dg/other/i386-3.C: Ditto.
>
>
> Bootstrap and new tests are passing, other testing is in progress.

Following is the correct definition of new insn:

--cut here--
Index: i386.md
===
--- i386.md (revision 190005)
+++ i386.md (working copy)
@@ -6604,6 +6604,27 @@
(set_attr "pent_pair" "pu")
(set_attr "mode" "")])

+(define_insn "adcx3"
+  [(set (reg:CCC FLAGS_REG)
+   (compare
+ (plus:SWI48
+   (match_operand:SWI48 1 "nonimmediate_operand" "%0")
+   (plus:SWI48
+ (match_operator 4 "ix86_carry_flag_operator"
+  [(match_operand 3 "flags_reg_operand") (const_int 0)])
+ (match_operand:SWI48 2 "nonimmediate_operand" "rm")))
+ (const_int 0)))
+   (set (match_operand:SWI48 0 "register_operand" "=r")
+   (plus:SWI48 (match_dup 1)
+   (plus:SWI48 (match_op_dup 4
+[(match_dup 3) (const_int 0)])
+   (match_dup 2]
+  "TARGET_ADX && ix86_binary_operator_ok (PLUS, mode, operands)"
+  "adcx\t{%2, %0|%0, %2}"
+  [(set_attr "type" "alu")
+   (set_attr "use_carry" "1")
+   (set_attr "mode" "")])
+
 (define_insn "*addsi3_carry_zext"
   [(set (match_operand:DI 0 "register_operand" "=r")
(zero_extend:DI
--cut here--

You don't need expander to emit insns via emit_insn (gen_).
Please put the code from the expander back to i386.c and rewrite the
sequence according to new insn pattern.

+  /* Generate CF from input operand.  */
+  emit_insn (gen_addqi3_cc (gen_reg_rtx (QImode), operands[2], constm1_rtx));

This insn should be in correct mode, you can make the pattern public if needed.

+  if (!REG_P (op1))
+   op1 = copy_to_mode_reg (QImode, op1);
+  else
+   op1 = gen_rtx_SUBREG (QImode, op1, 0);

This is not needed, just pass the register in the correct mode. You
should use something like:

  if (!insn_data[icode].operand[2].predicate (op1, mode1))
op1 = copy_to_mode_reg (mode1, op1);

Uros.

[PATCH] Intrinsics for ADCX

2012-07-31 Thread Michael Zolotukhin

Hi guys,
Here is a third part of patch, refactored by Kirill. This one adds
_addcarryx_u[32|64]  intrinsics.

Is it ok?

Changelog entry:
2012-07-31 Michael Zolotukhin 

* common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
(OPTION_MASK_ISA_ADX_UNSET): Likewise.
(ix86_handle_option): Handle madx option.
* config.gcc (i[34567]86-*-*): Add adxintrin.h.
(x86_64-*-*): Likewise.
* config/i386/adxintrin.h: New header.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect ADCX/ADOX
support.
* config/i386/i386-builtin-types.def
(UCHAR_FTYPE_UCHAR_UINT_UINT_PINT): New function type.
(UCHAR_FTYPE_UCHAR_ULONGLONG_ULONGLONG_PINT): Likewise.
* config/i386/i386-c.c: Define __ADX__ if needed.
* config/i386/i386.c (ix86_target_string): Define -madx option.
(PTA_ADX): New.
(ix86_option_override_internal): Handle new option.
(ix86_valid_target_attribute_inner_p): Add OPT_madx.
(ix86_builtins): Add IX86_BUILTIN_ADDCARRYX32,
IX86_BUILTIN_ADDCARRYX64.
(ix86_init_mmx_sse_builtins): Define corresponding built-ins.
(ix86_expand_builtin): Handle these built-ins.
(ix86_expand_args_builtin): Handle new function types.
* config/i386/i386.h (TARGET_ADX): New.
* config/i386/i386.md (adcx): New define_expand.
(adcx_carry): New define_insn.
* config/i386/i386.opt (madx): New.
* config/i386/x86intrin.h: Include adxintrin.h.

testsuite/Changelog entry:
2012-07-31 Michael Zolotukhin 

* gcc.target/i386/adx-addcarryx32-1.c: New.
* gcc.target/i386/adx-addcarryx32-2.c: New.
* gcc.target/i386/adx-addcarryx64-1.c: New.
* gcc.target/i386/adx-addcarryx64-2.c: New.
* gcc.target/i386/adx-check.h: New.
* gcc.target/i386/i386.exp (check_effective_target_adx): New.
* gcc.target/i386/sse-12.c: Add -madx.
* gcc.target/i386/sse-13.c: Ditto.
* gcc.target/i386/sse-14.c: Ditto.
* gcc.target/i386/sse-22.c: Ditto.
* gcc.target/i386/sse-23.c: Ditto.
* g++.dg/other/i386-2.C: Ditto.
* g++.dg/other/i386-3.C: Ditto.


Bootstrap and new tests are passing, other testing is in progress.


-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.


bdw-adx-1.gcc.patch
Description: Binary data

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-24 Thread Kirill Yukhin

> Can you please split the patch to three independent parts, prefetchw
> handling, rdseed and adxx. I got lost in the patch the second time.
Sure!

> I propose we start with prefetch. You are still changing prefetch
> patterns, while it should be enough to only change prefetch expander.
Actually, they're splitted since 3dnow has both prefetch and prefetchw
under single CPUID bit,
while under Intel's PRFTCH CPUID bit we have only prefetchw. So, old
pattern "*prefetch_3dnow_"
was set to be `prefetch` only for 3dnow, while new one is `prefetchw' only,
working both for PRFTCH and 3DNOW bits.

Changelog entry:
2012-07-24  Kirill Yukhin  
Michael Zolotukhin  

* common/config/i386/i386-common.c (OPTION_MASK_ISA_PRFCHW_SET): New.
(OPTION_MASK_ISA_PRFCHW_UNSET): Likewise.
(ix86_handle_option): Handle mprfchw option.
* config.gcc (i[34567]86-*-*): Add prfchwintrin.h.
(x86_64-*-*): Likewise.
* config/i386/prfchwintrin.h: New header.
* config/i386/cpuid.h (bit_PRFCHW): New.
(bit_BMI): Formatting fix.
(bit_HLE): Likewise.
(bit_RTM): Likewise.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect
PREFETCHW support.
* config/i386/i386-c.c: Define __PRFCHW__ if needed.
* config/i386/i386.c (ix86_target_string): Define
-mprfchw option. Formatting fixes.
(PTA_HLE): Formatting fix.
(PTA_PRFCHW): New.
(ix86_option_override_internal): Handle new option.
(ix86_valid_target_attribute_inner_p): Add OPT_mprfchw.
* config/i386/i386.h (TARGET_PRFCHW): New.
* config/i386/i386.md (prefetch): Enable for TARGET_PRFCHW.
(prefetchw_): New define_insn for write-prefetch.
(prefetch_3dnow_): Keep only read-prefetch here.
* config/i386/i386.opt (mprfchw): New.
* config/i386/mm3dnow.h: Move _m_prefetchw from here to
prfchwintrin.h.
* config/i386/x86intrin.h: Include prfchwintrin.h.

testsuite/Changelog entry:
2012-07-24  Kirill Yukhin  
Michael Zolotukhin  

* gcc.target/i386/prefetchw-1.c: New.
* gcc.target/i386/sse-12.c: Add -mprfchw.
* gcc.target/i386/sse-13.c: Ditto.
* gcc.target/i386/sse-14.c: Ditto.
* g++.dg/other/i386-2.C: Ditto.
* g++.dg/other/i386-3.C: Ditto.

patch is bootstrapping at the moment.

Any objections?

Thanks, K


bdw-prefetchw-1.gcc.patch
Description: Binary data

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-24 Thread Uros Bizjak

On Tue, Jul 24, 2012 at 2:09 PM, Kirill Yukhin  wrote:

> Uros, Jakub, thanks fr the inputs!
>
> I've refactored the patch appliying (hopefully) all of your inputs.
>
> It is attached.

Can you please split the patch to three independent parts, prefetchw
handling, rdseed and adxx. I got lost in the patch the second time.

I propose we start with prefetch. You are still changing prefetch
patterns, while it should be enough to only change prefetch expander.

Thanks,
Uros.

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-19 Thread Uros Bizjak

On Thu, Jul 19, 2012 at 11:51 AM, Jakub Jelinek  wrote:

> I think it is fine to change existing mm3dnow.h header, but not in the way
> it has been changed in the patch.  The thing is that unlike the newly added
> intrinsics headers, mm3dnow.h is still publicly includable header, and just
> including that header should work properly, so mm3dnow.h has to include
> prftchwintrin.h, which should be allowed to be included from x86intrin.h
> as well as mm3dnow.h, and that header should have guards, so that if both
> x86intrin.h is included and mm3dnow.h too (the latter first),
> prftchwintrin.h isn't included in twice.

Probably something like attached patch, with following changes to the
original patch:

+#if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED
+# error "Never use  directly; include  instead."
+#endif

No need to check for _IMMINTRIN_H_INCLUDED (in all new headers).

In config/i386/prfchwintrin.h, change this part to:

+#if !defined _X86INTRIN_H_INCLUDED && !defined _MM3DNOW_H_INCLUDED
+# error "Never use  directly; include 
or  instead."
+#endif

Uros.
Index: mm3dnow.h
===
--- mm3dnow.h   (revision 189643)
+++ mm3dnow.h   (working copy)
@@ -30,6 +30,7 @@
 #ifdef __3dNOW__
 
 #include 
+#include 
 
 extern __inline void __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _m_femms (void)
@@ -157,12 +158,6 @@
   __builtin_prefetch (__P, 0, 3 /* _MM_HINT_T0 */);
 }
 
-extern __inline void __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
-_m_prefetchw (void *__P)
-{
-  __builtin_prefetch (__P, 1, 3 /* _MM_HINT_T0 */);
-}
-
 extern __inline __m64 __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _m_from_float (float __A)
 {
Index: x86intrin.h
===
--- x86intrin.h (revision 189643)
+++ x86intrin.h (working copy)
@@ -97,4 +97,8 @@
 #include 
 #endif
 
+#ifdef __PRFCHW__
+#include 
+#endif
+
 #endif /* _X86INTRIN_H_INCLUDED */

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-19 Thread Uros Bizjak

On Thu, Jul 19, 2012 at 11:51 AM, Jakub Jelinek  wrote:

>> >> You have a mnemonic clash here. prefetchw is not good name for a new
>> >> instruction, it clashes with existing 3dnow name. Intel will need to
>> >> fix the spec, you probably won't be able to change prefetchw encoding
>> >> in binutils.
>> >
>> > From what I understand, Intel is using the same encoding of that insn as
>> > 3dNOW!, so there is no clash, just the same insn is now enabled by two ISAs
>> > (3dNOW! and this new CPUID prfchw bit).
>>
>> I see. Then please review prefetch changes to not change existing
>> functionality (i.e. -m3dnow should work as now, while -m3dnow -mprfchw
>> can emit new instructions everywhere). However, do not change existing
>> mm3dnow.h header.
>
> I think it is fine to change existing mm3dnow.h header, but not in the way
> it has been changed in the patch.  The thing is that unlike the newly added
> intrinsics headers, mm3dnow.h is still publicly includable header, and just
> including that header should work properly, so mm3dnow.h has to include
> prftchwintrin.h, which should be allowed to be included from x86intrin.h
> as well as mm3dnow.h, and that header should have guards, so that if both
> x86intrin.h is included and mm3dnow.h too (the latter first),
> prftchwintrin.h isn't included in twice.

Following (untested) patch solves insn generation issue:

--cut here--
Index: i386.md
===
--- i386.md (revision 189643)
+++ i386.md (working copy)
@@ -17662,7 +17662,8 @@
  supported by SSE counterpart or the SSE prefetch is not available
  (K6 machines).  Otherwise use SSE prefetch as it allows specifying
  of locality.  */
-  if (TARGET_3DNOW && (!TARGET_PREFETCH_SSE || rw))
+  if (rw && (TARGET_3DNOW || TARGET_PRFCHW)
+  || (TARGET_3DNOW && !TARGET_PREFETCH_SSE))
 operands[2] = GEN_INT (3);
   else
 operands[1] = const0_rtx;
@@ -17693,10 +17694,13 @@
   [(prefetch (match_operand:P 0 "address_operand" "p")
 (match_operand:SI 1 "const_int_operand" "n")
 (const_int 3))]
-  "TARGET_3DNOW"
+  "TARGET_3DNOW || TARGET_PRFCHW"
 {
   if (INTVAL (operands[1]) == 0)
-return "prefetch\t%a0";
+{
+  gcc_assert (!TARGET_PREFETCH_SSE);
+  return "prefetch\t%a0";
+}
   else
 return "prefetchw\t%a0";
 }
Index: i386.c
===
--- i386.c  (revision 189643)
+++ i386.c  (working copy)
@@ -3647,11 +3647,11 @@ ix86_option_override_internal (bool main_args_p)

   /* Turn on MMX builtins for -msse.  */
   if (TARGET_SSE)
-{
-  ix86_isa_flags |= OPTION_MASK_ISA_MMX & ~ix86_isa_flags_explicit;
-  x86_prefetch_sse = true;
-}
+ix86_isa_flags |= OPTION_MASK_ISA_MMX & ~ix86_isa_flags_explicit;

+  if (TARGET_SSE || TARGET_PRFCHW)
+x86_prefetch_sse = true;
+
   /* Turn on popcnt instruction for -msse4.2 or -mabm.  */
   if (TARGET_SSE4_2 || TARGET_ABM)
 ix86_isa_flags |= OPTION_MASK_ISA_POPCNT & ~ix86_isa_flags_explicit;
--cut here--

Uros.
>
> Jakub

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-19 Thread Jakub Jelinek

On Thu, Jul 19, 2012 at 11:23:09AM +0200, Uros Bizjak wrote:
> >> You have a mnemonic clash here. prefetchw is not good name for a new
> >> instruction, it clashes with existing 3dnow name. Intel will need to
> >> fix the spec, you probably won't be able to change prefetchw encoding
> >> in binutils.
> >
> > From what I understand, Intel is using the same encoding of that insn as
> > 3dNOW!, so there is no clash, just the same insn is now enabled by two ISAs
> > (3dNOW! and this new CPUID prfchw bit).
> 
> I see. Then please review prefetch changes to not change existing
> functionality (i.e. -m3dnow should work as now, while -m3dnow -mprfchw
> can emit new instructions everywhere). However, do not change existing
> mm3dnow.h header.

I think it is fine to change existing mm3dnow.h header, but not in the way
it has been changed in the patch.  The thing is that unlike the newly added
intrinsics headers, mm3dnow.h is still publicly includable header, and just
including that header should work properly, so mm3dnow.h has to include
prftchwintrin.h, which should be allowed to be included from x86intrin.h
as well as mm3dnow.h, and that header should have guards, so that if both
x86intrin.h is included and mm3dnow.h too (the latter first),
prftchwintrin.h isn't included in twice.

Jakub

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-19 Thread Kirill Yukhin

> -  else
> -return "prefetchw\t%a0";
> -}
> +  "prefetch\t%a0"
>
> You have a mnemonic clash here. prefetchw is not good name for a new
> instruction, it clashes with existing 3dnow name. Intel will need to
> fix the spec, you probably won't be able to change prefetchw encoding
> in binutils.

Hi Uros,
prefetchw from Intel's recent spec is identical to one from AMD's 3Dnow.
So, they don't clash, this is just a support of prefetchw on Intel HW

Thanks, K

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-19 Thread Uros Bizjak

On Thu, Jul 19, 2012 at 11:10 AM, Jakub Jelinek  wrote:
> On Thu, Jul 19, 2012 at 11:03:25AM +0200, Uros Bizjak wrote:
>> +  /* Set CF to specified value.  */
>> +  emit_insn (gen_addqi3_cc(
>> +   gen_reg_rtx(QImode),
>> +   op1,
>> +   constm1_rtx));
>> +
>>
>> This should be in the *.md expander.
>
> Note also that the formatting of the above was wrong for multiple reasons.
>
>>  (define_insn "*prefetch_3dnow_"
>>[(prefetch (match_operand:P 0 "address_operand" "p")
>> -  (match_operand:SI 1 "const_int_operand" "n")
>> +  (const_int 0)
>>(const_int 3))]
>>"TARGET_3DNOW"
>> -{
>> -  if (INTVAL (operands[1]) == 0)
>> -return "prefetch\t%a0";
>> -  else
>> -return "prefetchw\t%a0";
>> -}
>> +  "prefetch\t%a0"
>>
>> You have a mnemonic clash here. prefetchw is not good name for a new
>> instruction, it clashes with existing 3dnow name. Intel will need to
>> fix the spec, you probably won't be able to change prefetchw encoding
>> in binutils.
>
> From what I understand, Intel is using the same encoding of that insn as
> 3dNOW!, so there is no clash, just the same insn is now enabled by two ISAs
> (3dNOW! and this new CPUID prfchw bit).

I see. Then please review prefetch changes to not change existing
functionality (i.e. -m3dnow should work as now, while -m3dnow -mprfchw
can emit new instructions everywhere). However, do not change existing
mm3dnow.h header.

Uros.

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-19 Thread Jakub Jelinek

On Thu, Jul 19, 2012 at 11:03:25AM +0200, Uros Bizjak wrote:
> +  /* Set CF to specified value.  */
> +  emit_insn (gen_addqi3_cc(
> +   gen_reg_rtx(QImode),
> +   op1,
> +   constm1_rtx));
> +
> 
> This should be in the *.md expander.

Note also that the formatting of the above was wrong for multiple reasons.

>  (define_insn "*prefetch_3dnow_"
>[(prefetch (match_operand:P 0 "address_operand" "p")
> -  (match_operand:SI 1 "const_int_operand" "n")
> +  (const_int 0)
>(const_int 3))]
>"TARGET_3DNOW"
> -{
> -  if (INTVAL (operands[1]) == 0)
> -return "prefetch\t%a0";
> -  else
> -return "prefetchw\t%a0";
> -}
> +  "prefetch\t%a0"
> 
> You have a mnemonic clash here. prefetchw is not good name for a new
> instruction, it clashes with existing 3dnow name. Intel will need to
> fix the spec, you probably won't be able to change prefetchw encoding
> in binutils.

>From what I understand, Intel is using the same encoding of that insn as
3dNOW!, so there is no clash, just the same insn is now enabled by two ISAs
(3dNOW! and this new CPUID prfchw bit).

Jakub

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-19 Thread Uros Bizjak

Hello!

> This patch adds new intrinsics for new ADCX, ADOX, RDSEED and
> PREFETCHW instructions, introduced here:
> http://software.intel.com/en-us/avx/

+/* Copyright (C) 2012 Free Software Foundation, Inc.
+   Contributed by Michael Zolotukhin.

Please remove "Contributed by" lines from headers.

+
+  /* Set CF to specified value.  */
+  emit_insn (gen_addqi3_cc(
+ gen_reg_rtx(QImode),
+ op1,
+ constm1_rtx));
+

This should be in the *.md expander.

+  /* Return current CF value.  */
+  emit_insn (gen_rtx_SET (QImode, target,
+   gen_rtx_LTU (QImode, gen_rtx_REG (CCCmode, FLAGS_REG), 
const0_rtx)));

Also this.

+(define_attr "isa"
"base,sse2,sse2_noavx,sse3,sse4,sse4_noavx,noavx,avx,avx2,noavx2,bmi2,rdseed,adx,prfchw"

No need to add unused isa attributes.

+(eq_attr "isa" "rdseed") (symbol_ref "TARGET_RDSEED")
+(eq_attr "isa" "adx") (symbol_ref "TARGET_ADX")
+(eq_attr "isa" "prfchw") (symbol_ref "TARGET_PRFCHW")

This is not needed.

+(define_insn "adcx"
+  [
+   (set (match_operand:SWI48 0 "register_operand" "=r")
+   (unspec:SWI48
+ [(match_operand:SWI48 1 "nonimmediate_operand" "%0")
+  (match_operand:SWI48 2 "nonimmediate_operand" "rme")
+  (reg:CC FLAGS_REG)
+  ]UNSPEC_ADCX))
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_ADX"
+  "adcx\t{%2, %0|%0, %2}"
+  [(set_attr "mode" "")])

Do we really need unspec? It is a specialized version of a PLUS RTX,
please see *3_carry.

 (define_insn "*prefetch_3dnow_"
   [(prefetch (match_operand:P 0 "address_operand" "p")
-(match_operand:SI 1 "const_int_operand" "n")
+(const_int 0)
 (const_int 3))]
   "TARGET_3DNOW"
-{
-  if (INTVAL (operands[1]) == 0)
-return "prefetch\t%a0";
-  else
-return "prefetchw\t%a0";
-}
+  "prefetch\t%a0"

You have a mnemonic clash here. prefetchw is not good name for a new
instruction, it clashes with existing 3dnow name. Intel will need to
fix the spec, you probably won't be able to change prefetchw encoding
in binutils.

Please also add new compile flags to
gcc.target/i386/sse-{12,13,14,22,23}.c and g++.dg/other/i386-{2,3}.C.

BTW: Where are ADOX intrinsics?

Uros.

[PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

2012-07-18 Thread Michael Zolotukhin

Hi,
This patch adds new intrinsics for new ADCX, ADOX, RDSEED and
PREFETCHW instructions, introduced here:
http://software.intel.com/en-us/avx/

Bootstrapped on x86-64, testing is in progress.

Is it ok for trunk?

Changelog entry:
2012-07-17  Michael Zolotukhin  

* common/config/i386/i386-common.c (OPTION_MASK_ISA_RDSEED_SET): New.
(OPTION_MASK_ISA_ADX_SET): Likewise.
(OPTION_MASK_ISA_PRFCHW_SET): Likewise.
(OPTION_MASK_ISA_RDSEED_UNSET): Likewise.
(OPTION_MASK_ISA_ADX_UNSET): Likewise.
(OPTION_MASK_ISA_PRFCHW_UNSET): Likewise.
(ix86_handle_option): Handle mrdseed, madx and mprfchw options.
* config.gcc (i[34567]86-*-*): Add rdseedintrin.h, adxintrin.h and
prfchwintrin.h.
(x86_64-*-*): Likewise.
* config/i386/adxintrin.h: New header.
* config/i386/prfchwintrin.h: Likewise.
* config/i386/rdseedintrin.h: Likewise.
* config/i386/cpuid.h (bit_RDSEED): New.
(bit_ADX): Likewise.
(bit_PRFCHW): Likewise.
(bit_BMI): Formatting fix.
(bit_HLE): Likewise.
(bit_RTM): Likewise.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect ADCX/ADOX,
RDSEED and PREFETCHW support.
* config/i386/i386-builtin-types.def
(UCHAR_FTYPE_UCHAR_UINT_UINT_PINT): New function type.
(UCHAR_FTYPE_UCHAR_ULONGLONG_ULONGLONG_PINT): Likewise.
* config/i386/i386-c.c: Define __RDSEED__, __ADX__, and __PRFCHW__ if
needed.
* config/i386/i386.c (ix86_target_string): Define -mrdseed, -madx,
-mprfchw options. Formatting fixes.
(PTA_HLE): Formatting fix.
(PTA_RDSEED): New.
(PTA_ADX): Likewise.
(PTA_PRFCHW): Likewise.
(ix86_option_override_internal): Handle new options.
(ix86_valid_target_attribute_inner_p): Add OPT_mrdseed, OPT_madx, and
OPT_mprfchw.
(ix86_builtins): Add IX86_BUILTIN_ADDXCARRY32,
IX86_BUILTIN_ADDXCARRY64, IX86_BUILTIN_RDSEED16,
IX86_BUILTIN_RDSEED32, IX86_BUILTIN_RDSEED64.
(ix86_init_mmx_sse_builtins): Define corresponding built-ins.
(ix86_expand_builtin): Handle these built-ins.
(ix86_expand_args_builtin): Handle new function types.
* config/i386/i386.h (TARGET_RDSEED): New.
(TARGET_ADX): Likewise.
(TARGET_PRFCHW): Likewise.
* config/i386/i386.md (UNSPEC_ADCX): New.
(UNSPEC_RDSEED): Likewise.
(attributes): Add rdseed, adx, prfchw.
(adcx): New define_insn.
(rdseed): Likewise.
(prefetch): Enable for TARGET_PRFCHW.
(prefetchw_): New define_insn for write-prefetch.
(prefetch_3dnow_): Keep only read-prefetch here.
* config/i386/i386.opt (mrdseed): New.
(madx): Likewise.
(mprfchw): Likewise.
* config/i386/mm3dnow.h: Move _m_prefetchw from here to
prfchwintrin.h.
* config/i386/x86intrin.h: Include prfchwintrin.h, rdseedintrin.h,
adxintrin.h.

testsuite/Changelog entry:
2012-07-17  Michael Zolotukhin  

* gcc.target/i386/adx-addxcarry32-1.c: New.
* gcc.target/i386/adx-addxcarry32-2.c: New.
* gcc.target/i386/adx-addxcarry64-1.c: New.
* gcc.target/i386/adx-addxcarry64-2.c: New.
* gcc.target/i386/adx-check.h: New.
* gcc.target/i386/i386.exp: New.
* gcc.target/i386/prefetchw-1.c: New.
* gcc.target/i386/rdseed16-1.c: New.
* gcc.target/i386/rdseed32-1.c: New.
* gcc.target/i386/rdseed64-1.c: New.

-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.


adx_rdseed_prefetchw_intrin.patch
Description: Binary data

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX

[PATCH] Intrinsics for ADCX

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

Re: [PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

[PATCH] Intrinsics for ADCX, ADOX, RDSEED and PREFETCHW

24 matches

Site Navigation

Mail list logo

Footer information