This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Compiling for single-threaded use (implicit threading support difference in 4.9.1 vs. 4.8.1)
- From: leon zadorin <leonleon77 at gmail dot com>
- To: gcc-help <gcc-help at gcc dot gnu dot org>
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, Johan Alfredsson <sduvan dot gcc at gmail dot com>
- Date: Thu, 16 Oct 2014 10:15:08 +1100
- Subject: Re: Compiling for single-threaded use (implicit threading support difference in 4.9.1 vs. 4.8.1)
- Authentication-results: sourceware.org; auth=none
- References: <CA+pZiO6XXzJ7y-qu_F167ruqRwvZc8Sxnj4EAH2rXZwiODPbyw at mail dot gmail dot com> <CA+pZiO77AOuMR671vKsE4un1cspRkKAJaesD_Xe5KXMPgMY1YA at mail dot gmail dot com> <CAH6eHdRBuh7LZr3JaRmFgYuOeF_S5j4aLjtvgdATLvpQtBsKoQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 11 dot 1410151327210 dot 8286 at stedding dot saclay dot inria dot fr>
On Wed, Oct 15, 2014 at 10:40 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Wed, 15 Oct 2014, Jonathan Wakely wrote:
>
>> On 14 October 2014 18:29, Johan Alfredsson wrote:
>>>
>>> As my application is single-threaded, I don't want to pay the
>>> performance penalty of mutexes etc. Hence, my question is if it is
>>> possible to explicitly request gcc to compile my application in
>>> single-threaded mode.
>>
>>
>> It should happen automatically, there's no way to request it because
>> there should be no need.
>
>
> Well, I would quite like a compilation flag -fI-promise-not-to-use-threads,
> that would automatically turn atomics into plain variables with regular
> operations, turn TLS into regular memory, remove locks, etc, and perform all
> the optimizations this enables. It isn't quite the same as a runtime test
> that only skips a few mutexes in the library.
Yeah, that would be awesome :) I would love to get a feel for how gcc
is currently poised with respect to devoting development resources
towards retaining single-thread optimizations based of command-line
switches... I guess with limited resources (developers' time et. al.)
this may need to be seen in perspective... although, personally, I
would love to see aggressive single-thread optimizations wherever
possible (e.g. programmer setting a "green light" switch for
single-threaded assumptions, even on c++{11,14} code with assumptions
that it doesn't use any of the "multi-threaded" features of the
language) :) :) :)
As far as I know of this stuff, the non-gcc llvm/clang has just
introduced -mthread-model=single to clang (and -thread-model=single
with -loweratomic being available to "opt" bitcode optimizer
previously already for quite some time)... however, at this time,
mostly appears to be implemented for ARM-based architectures... but
this is taking me outside the GCC context...