From: Laurent GUERBY <laurent@guerby.net>
To: Loic Dachary <loic@dachary.org>
Cc: Kevin Greenan <kmgreen2@gmail.com>,
Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: GCC -msse2 portability question
Date: Tue, 25 Mar 2014 12:22:52 +0100 [thread overview]
Message-ID: <1395746572.15058.219.camel@pc2> (raw)
In-Reply-To: <533152E9.50709@dachary.org>
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
> >
>
next prev parent reply other threads:[~2014-03-25 11:23 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 [this message]
2014-03-25 14:44 ` Milosz Tanski
2014-03-25 18:45 ` Loic Dachary
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=1395746572.15058.219.camel@pc2 \
--to=laurent@guerby.net \
--cc=ceph-devel@vger.kernel.org \
--cc=kmgreen2@gmail.com \
--cc=loic@dachary.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.