Hi,
I was debugging some performance issues with an application that uses
the gcc builtin lock functions on powerpc. A simple test case:
long lock_try(long *value)
{
return __sync_lock_test_and_set(value, 1);
}
long unlock(long *value)
{
__sync_lock_release(value);
}
0010 :
On Tue, Sep 02, 2008 at 10:04:05PM -0400, Dennis Clarke wrote:
> I really do value the build status reports submitted by
> others and I go searching for a few results in particular.
> People like Joe Buck can be relied upon to post good looking
> results for Solaris and thus I need to be able to fi
reducing identical builds?
Let's say I
cd
/configure -build i686-pc-cygwin -host i686-pc-cygwin -target i686-pc-cygwin
make
make install
cd
/configure -build i686-pc-cygwin -host i686-pc-cygwin -target
sparc-sun-solaris2.10
make
make install
cd
/configure -build i686-pc-cy
Hi,
I noticed that sync_lock_release uses lwsync if available but every other
sync_* builtin uses a heavyweight sync. eg:
0060 :
60: 7c 00 04 ac sync
64: 7c 69 1b 78 mr r9,r3
68: 7c 60 48 28 lwarx r3,0,r9
6c: 39 63 00 01 addir11,r3,1
70: 7d
> On Tue, Sep 02, 2008 at 10:04:05PM -0400, Dennis Clarke wrote:
>> I really do value the build status reports submitted by
>> others and I go searching for a few results in particular.
>> People like Joe Buck can be relied upon to post good looking
>> results for Solaris and thus I need to be abl
On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>>
>> If using DF seems like the Right Thing, we could simply apply both
>> patches, which would give a similar same allocno order to the one
>> we have now. But it seemed better to look a bit deeper first...
>>
>
> Richar
On Tue, 2008-09-02 at 22:42 -0300, Tobias Grosser wrote:
> On Tue, 2008-09-02 at 14:54 -0700, Janis Johnson wrote:
> > On Tue, 2008-09-02 at 21:23 +, Joseph S. Myers wrote:
> > > On Tue, 2 Sep 2008, Andrew Pinski wrote:
> > >
> > > > On Tue, Sep 2, 2008 at 2:15 PM, Tobias Grosser
> > > > <[EMA
On Wed, 2008-09-03 at 10:11 -0400, Dennis Clarke wrote:
> > On Tue, Sep 02, 2008 at 10:04:05PM -0400, Dennis Clarke wrote:
> >> I really do value the build status reports submitted by
> >> others and I go searching for a few results in particular.
> >> People like Joe Buck can be relied upon to pos
Anton Blanchard wrote:
I noticed that sync_lock_release uses lwsync if available but every other
sync_* builtin uses a heavyweight sync. eg:
Every other sync builtin has full-barrier semantics. AFAIK, isync is
correct.
r~
On Wed, Sep 03, 2008 at 10:14:38AM -0700, Janis Johnson wrote:
> That human is me, and I'm once again behind on almost everything.
> I'll try to get to that soon. Thanks for the reminder that the
> results are useful.
Here are a couple to start off the results page:
1) x86_64-unknown-linux-gnu,
On Tue, Sep 2, 2008 at 8:42 PM, Tobias Grosser
<[EMAIL PROTECTED]> wrote:
> It seems this code is already there, but the check for
> "check_effective_target_fgraphite" fails. I attached a patch. Now the
> graphite test cases are only executed, if graphite is available.
>
The patch looks good: the
> On Wed, Sep 03, 2008 at 10:14:38AM -0700, Janis Johnson wrote:
>> That human is me, and I'm once again behind on almost everything.
I can relate. :-(
>> I'll try to get to that soon. Thanks for the reminder that the
>> results are useful.
>
> Here are a couple to start off the results page:
>
On Wed, Sep 3, 2008 at 11:06 AM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 2, 2008 at 8:42 PM, Tobias Grosser
> <[EMAIL PROTECTED]> wrote:
>> It seems this code is already there, but the check for
>> "check_effective_target_fgraphite" fails. I attached a patch. Now the
>> graphite test
"H.J. Lu" <[EMAIL PROTECTED]> writes:
> On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>>>
>>> If using DF seems like the Right Thing, we could simply apply both
>>> patches, which would give a similar same allocno order to the one
>>> we have now. But it seemed better
On Wed, Sep 03, 2008 at 11:19:37AM -0700, Andrew Pinski wrote:
> On Wed, Sep 3, 2008 at 11:06 AM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> > On Tue, Sep 2, 2008 at 8:42 PM, Tobias Grosser
> > <[EMAIL PROTECTED]> wrote:
> >> It seems this code is already there, but the check for
> >> "check_effect
On Wed, Sep 3, 2008 at 11:19 AM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
> "H.J. Lu" <[EMAIL PROTECTED]> writes:
>> On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
If using DF seems like the Right Thing, we could simply apply both
patches, which would
On Wed, Sep 3, 2008 at 1:19 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Maybe it is better to error out if -fgraphite is used even without
> optimization if the compiler does not have the required libraries.
>
Patch attached.
Sebastian
* toplev.c (process_options): Fail and warn when graphit
On Wed, Sep 3, 2008 at 1:24 PM, Steve Kargl
<[EMAIL PROTECTED]> wrote:
> I think that this is sensible considering that cloog is only
> available through a git repository. Requiring people to install
> git to build cloog is somewhat un-user-friendly.
I will prepare a cloog.tar.gz and will put it
Richard Sandiford wrote:
"H.J. Lu" <[EMAIL PROTECTED]> writes:
On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
If using DF seems like the Right Thing, we could simply apply both
patches, which would give a similar same allocno order to the one
we have now. B
"H.J. Lu" <[EMAIL PROTECTED]> writes:
> On Wed, Sep 3, 2008 at 11:19 AM, Richard Sandiford
> <[EMAIL PROTECTED]> wrote:
>> "H.J. Lu" <[EMAIL PROTECTED]> writes:
>>> On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>
> If using DF seems like the Right Thing, we cou
Vladimir Makarov <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> "H.J. Lu" <[EMAIL PROTECTED]> writes:
>>
>>> On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>>>
> If using DF seems like the Right Thing, we could simply apply both
> patches, whi
On Wed, Sep 3, 2008 at 3:06 AM, Anton Blanchard <[EMAIL PROTECTED]> wrote:
> unlock looks good, but lock has both release and acquire barriers. Even
> worse, the release barrier is a heavyweight sync which is very slow.
> Looking at the gcc documentation, sync_lock_test_and_set only needs an
> aqui
Richard Sandiford wrote:
"H.J. Lu" <[EMAIL PROTECTED]> writes:
On Wed, Sep 3, 2008 at 11:19 AM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
"H.J. Lu" <[EMAIL PROTECTED]> writes:
On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
If using DF se
David Edelsohn wrote:
On Wed, Sep 3, 2008 at 3:06 AM, Anton Blanchard <[EMAIL PROTECTED]> wrote:
Why does the GCC alpha port emit a memory barrier at the beginning of the
test_and_set sync builtin sequence, which seems to be more than
the required `acquire' semantics?
Um, that's a good question
Richard Sandiford wrote:
Vladimir Makarov <[EMAIL PROTECTED]> writes:
Richard Sandiford wrote:
"H.J. Lu" <[EMAIL PROTECTED]> writes:
On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
If using DF seems like the Right Thing, we could sim
Vladimir Makarov <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> But as I said to HJ, I'm happy to apply the DF patch in isolation,
>> as long as we accept that the benefit of fixing a correctness
>> regression outweighs the potential performance regression.
>>
> Sure, regression is mo
Janis Johnson wrote:
That human is me, and I'm once again behind on almost everything.
I'll try to get to that soon. Thanks for the reminder that the
results are useful.
By the way, I could be talked into handing over this responsibility
to someone else willing to do it.
I've posted patches f
Snapshot gcc-4.2-20080903 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080903/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi Richard,
>> I noticed that sync_lock_release uses lwsync if available but every other
>> sync_* builtin uses a heavyweight sync. eg:
>
> Every other sync builtin has full-barrier semantics. AFAIK, isync is
> correct.
I think we can change the sync to an lwsync and still maintain full
barri
> Janis Johnson wrote:
>> That human is me, and I'm once again behind on almost everything.
>> I'll try to get to that soon. Thanks for the reminder that the
>> results are useful.
>>
>> By the way, I could be talked into handing over this responsibility
>> to someone else willing to do it.
I wo
Within the last two days my MIPS bootstraps are failing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
It worked back on:
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00118.html
David Daney
On Wed, Sep 3, 2008 at 6:53 PM, Anton Blanchard <[EMAIL PROTECTED]> wrote:
> The only thing lwsync wont order is a store followed by a load. Since
> the lwsync will always be paired with a store (the stwcx), we will order
> all accesses before it and provide a release barrier.
Anton,
My one other
On Wed, Sep 3, 2008 at 6:09 PM, David Edelsohn <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 3, 2008 at 6:53 PM, Anton Blanchard <[EMAIL PROTECTED]> wrote:
>> The only thing lwsync wont order is a store followed by a load. Since
>> the lwsync will always be paired with a store (the stwcx), we will order
The release of MPFR 2.3.2 is imminent. Please help to make this
release as good as possible by downloading and testing this
release candidate:
http://www.mpfr.org/mpfr-2.3.2/mpfr-2.3.2-rc1.tar.lzma
http://www.mpfr.org/mpfr-2.3.2/mpfr-2.3.2-rc1.tar.bz2
http://www.mpfr.org/mpfr-2.3.2/mpfr-2.3.2-rc1.
Hi David,
> My one other concern is developers using the builtins for applications on
> embedded PowerPC processors. lwsync will not order accesses to device
> memory space, AFAICT. I do not know if developers would rely on GCC builtins
> in that context and assume it implements the correct se
35 matches
Mail list logo
