CEPH filesystem development
 help / color / mirror / Atom feed
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
> > 
> 



  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox