This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86: _mm512_set1_p[sd]


Hello!

> On Mon, Mar 24, 2014 at 12:13 PM, Ulrich Drepper <drepper@gmail.com> wrote:
>>> Your patch is correct IMHO, but maybe it worst to add all missing
>>> `mm512_set1*' stuff?
>>>
>>> According to trunk and [1] we're still missing (beside mentioned by you)
>>> _mm512_set1_epi16 and  _mm512_set1_epi8 broadcasts.
>>
>> Yes, more are missing, but I think those will need new builtins.  The
>> _ps and _pd don't require additional instructions.
>>
>> _mm512_set1_epi16 might have to map to vpbroadcastw. _mm512_set1_epi8
>> might have to map to vpbroadcastb.  I haven't seen a way to generate
>> those instructions if needed and so this work was out of scope for now
>> due to time constraints.  I agree, they should be added as quickly as
>> possible to avoid releasing headers with incomplete APIs.
>>
>> What is the verdict on checking these changes in?  Too late for the
>> next release?
>
> This kind of changes can also be made for 4.9.1 for example.

OTOH, these changes are isolated to intrinsic header files, and we
have quite extensive testsuite for these. I see no problem to check-in
these changes even at this stage.

So, if there is no better solution I propose to check these changes
in, since the benefit to users outweight (minor) risk. Would this be
OK from RM POV, also weighting in benefits to users?

Uros


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]