From: Loic Dachary <loic@dachary.org>
To: Milosz Tanski <milosz@adfin.com>
Cc: Kevin Greenan <kmgreen2@gmail.com>,
Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: GCC -msse2 portability question
Date: Tue, 25 Mar 2014 19:45:36 +0100 [thread overview]
Message-ID: <5331CED0.8010103@dachary.org> (raw)
In-Reply-To: <CANP1eJEYea5=tdxPVAe7G8aY30HZGb-MqdHAhCaoigtYEX3s-w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4416 bytes --]
Thanks, I did not know about this attribute :-)
On 25/03/2014 15:44, Milosz Tanski wrote:
> Loic,
>
> If you're already doing a runtime checking of these bits before
> calling the functions you want to optimize then you can use the gcc
> Function Specific Opt feature of GCC.
> http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Function-Attributes.html#index-g_t_0040code_007btarget_007d-function-attribute-2259
>
> Basically you add a target attribute to a function (specifying use SSE version).
>
> void my_optimized_function(void* sse_vec, size_t n)
> __attribute__ ((__target__ ("sse4.2")));
>
> It's available from GCC 4.4 and on. That happens to be the GCC version
> on RHEL6, Debian Squeeze, Ubuntu 10.04 LTS. Hopefully that's good
> enough and you can omit the optimization on people on platforms older
> than that.
>
> Best,
> - Milosz
>
>
> On Tue, Mar 25, 2014 at 7:22 AM, Laurent GUERBY <laurent@guerby.net> wrote:
>> On Tue, 2014-03-25 at 10:56 +0100, Loic Dachary wrote:
>>> Hi Laurent,
>>
>> Hi Loic,
>>
>>> It occurs to me that all we're after is to enable SSE functions such as _mm_set_epi32. We're not trying to have the binary optimized in any implicit way, it is all explicit. The problem seems to be that -msse4.2 will do both
>>>
>>> * activate _mm_set_epi32 etc functions
>>> * optimize the binary to use sse4.2 instructions
>>>
>>> Do you know of a compiler flag that would only
>>>
>>> * activate _mm_set_epi32 etc functions
>>
>> This is a function part of an Intel defined standard to access processor
>> feature, this standard will have one or more implementation depending on
>> your compiler/libc/OS. IIRC these functions are closely aligned with
>> specific processor feature, if the feature isn't there in general it
>> makes no sense to use them.
>>
>> In the particular case of _mm_set_epi32 it seems
>> to be a data formating inline function:
>>
>> /usr/lib/gcc/x86_64-linux-gnu/4.7.2/include/emmintrin.h
>> ...
>> typedef long long __m128i __attribute__ ((__vector_size__ (16),
>> __may_alias__));
>> ...
>> extern __inline __m128i __attribute__((__gnu_inline__,
>> __always_inline__, __artificial__))
>> _mm_set_epi32 (int __q3, int __q2, int __q1, int __q0)
>> {
>> return __extension__ (__m128i)(__v4si){ __q0, __q1, __q2, __q3 };
>> }
>>
>> Functions in this include files are using GCC builtins:
>>
>> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions
>>
>> To avoid any issue I wouldn't use these functions at all
>> on a non SSE machine.
>>
>> Sincerely,
>>
>> Laurent
>>
>>> and not
>>>
>>> * optimize the binary to use sse4.2 instructions
>>>
>>> ? It may be a RTFM question and I apologize for that. Reading http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options it looks like this is more or less what --mtune=corei7-avx would do (because gf-complete uses PCLMUL when available). But it feels weird to specify a specific processor model where what we need is a set of features.
>>>
>>> Thanks for your help :-)
>>>
>>> On 25/03/2014 10:43, Laurent GUERBY wrote:
>>>> On Mon, 2014-03-24 at 22:27 +0100, Loic Dachary wrote:
>>>>>
>>>>> On 23/03/2014 23:34, Laurent GUERBY wrote:
>>>>>> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options
>>>>>>
>>>>>> So unless you want to run your code a very very old x86 32 bit processor
>>>>>> "-msse" shouldn't be an issue. "-msse2" is similar.
>>>>>
>>>>> This is good to know :) Should I be worried about unintended side effects of -msse4.2 -mssse3 -msse4.1 or -mpclmul ? These are the flags that gf-complete are using, specifically.
>>>>
>>>> Hi,
>>>>
>>>> SSE4.2 will be available only in more recent
>>>> processors as documented on the page above.
>>>>
>>>> If your library already is dynamically checking for processor
>>>> feature I would advise to be conservative in your
>>>> -m flags, ie using what debian would use for maximum
>>>> x86 portability.
>>>>
>>>> Sincerely,
>>>>
>>>> Laurent
>>>>
>>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
Loïc Dachary, Artisan Logiciel Libre
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2014-03-25 18:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-23 19:50 GCC -msse2 portability question Loic Dachary
2014-03-23 22:34 ` Laurent GUERBY
2014-03-24 21:27 ` Loic Dachary
2014-03-25 9:43 ` Laurent GUERBY
2014-03-25 9:56 ` Loic Dachary
2014-03-25 11:22 ` Laurent GUERBY
2014-03-25 14:44 ` Milosz Tanski
2014-03-25 18:45 ` Loic Dachary [this message]
2014-03-24 1:40 ` Sage Weil
2014-03-25 19:08 ` Loic Dachary
[not found] ` <CA+AFVBhpOZEPehsd4qHCBr4aRzv60ZW8LzRwKsduUrZmLV1wxQ@mail.gmail.com>
2014-03-25 19:21 ` Loic Dachary
2014-03-25 19:46 ` Milosz Tanski
[not found] ` <CA+AFVBgOEz8_fv9H-8_kOuVSJNL3KQ+36b5kscfjnRMs09DZ6Q@mail.gmail.com>
[not found] ` <53327E59.7060408@dachary.org>
[not found] ` <CANP1eJG9xoCPkFs19KXG1RPUqc-D3aO_0SBOM=4WWFRN2JtX=g@mail.gmail.com>
2014-03-26 18:24 ` Loic Dachary
[not found] ` <CANP1eJErc4qnRhtOCs=Cnh6VNtihLVcZxB1PSCQjpH0sFDBuWA@mail.gmail.com>
2014-03-26 22:13 ` Loic Dachary
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5331CED0.8010103@dachary.org \
--to=loic@dachary.org \
--cc=ceph-devel@vger.kernel.org \
--cc=kmgreen2@gmail.com \
--cc=milosz@adfin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox