* Java: add flag_use_atomic_builtins
@ 2009-08-12 16:09 Andrew Haley
2009-08-12 16:49 ` Joseph S. Myers
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Haley @ 2009-08-12 16:09 UTC (permalink / raw)
To: java-patches, Gcc Patch List
Some targets, particularly ARM, don't have instructions for things
such as sync_compare_and_swap. Instead, a routine in libgcc is
used. This patch adds a new gcj option, -fuse-atomic-builtins,
which causes gcj to use the routines in libgcc whenever atomic
operations are needed.
Andrew.
2009-08-12 Andrew Haley <aph@redhat.com>
* builtins.c (compareAndSwapInt_builtin): Use
flag_use_atomic_builtins.
(compareAndSwapLong_builtin): Likewise.
(compareAndSwapObject_builtin): Likewise.
* jvspec.c: Add flag_use_atomic_builtins.
* gcj.texi: Likewise.
* java-tree.h: Likewise.
* lang.opt: Likewise.
Index: java/builtins.c
===================================================================
--- java/builtins.c (revision 150696)
+++ java/builtins.c (working copy)
@@ -318,7 +318,8 @@
tree orig_call)
{
enum machine_mode mode = TYPE_MODE (int_type_node);
- if (sync_compare_and_swap[mode] != CODE_FOR_nothing)
+ if (sync_compare_and_swap[mode] != CODE_FOR_nothing
+ || flag_use_atomic_builtins)
{
tree addr, stmt;
UNMARSHAL5 (orig_call);
@@ -337,7 +338,12 @@
tree orig_call)
{
enum machine_mode mode = TYPE_MODE (long_type_node);
- if (sync_compare_and_swap[mode] != CODE_FOR_nothing)
+ if (sync_compare_and_swap[mode] != CODE_FOR_nothing
+ || (GET_MODE_SIZE (mode) <= GET_MODE_SIZE (word_mode)
+ && flag_use_atomic_builtins))
+ /* We don't trust flag_use_atomic_builtins for multi-word
+ compareAndSwap. Some machines such as ARM have atomic libfuncs
+ but not the multi-word versions. */
{
tree addr, stmt;
UNMARSHAL5 (orig_call);
@@ -355,7 +361,8 @@
tree orig_call)
{
enum machine_mode mode = TYPE_MODE (ptr_type_node);
- if (sync_compare_and_swap[mode] != CODE_FOR_nothing)
+ if (sync_compare_and_swap[mode] != CODE_FOR_nothing
+ || flag_use_atomic_builtins)
{
tree addr, stmt;
int builtin;
Index: java/jvspec.c
===================================================================
--- java/jvspec.c (revision 150696)
+++ java/jvspec.c (working copy)
@@ -73,6 +73,7 @@
%<fclasspath* %<fCLASSPATH* %<fbootclasspath*\
%<fextdirs*\
%<fuse-divide-subroutine %<fno-use-divide-subroutine\
+ %<fuse-atomic-builtins %<fno-use-atomic-builtins\
%<fcheck-references %<fno-check-references\
%<ffilelist-file %<fsaw-java-file %<fsource* %<ftarget*\
%{f*} -fdollars-in-identifiers\
Index: java/lang.opt
===================================================================
--- java/lang.opt (revision 150696)
+++ java/lang.opt (working copy)
@@ -192,6 +192,10 @@
Java Var(flag_use_divide_subroutine) Init(1)
Call a library routine to do integer divisions
+fuse-atomic-builtins
+Java Var(flag_use_atomic_builtins) Init(0)
+Generate code for built-in atomic operations
+
fbootstrap-classes
Java Var(flag_bootstrap_classes)
Generated should be loaded by bootstrap loader
Index: java/java-tree.h
===================================================================
--- java/java-tree.h (revision 150696)
+++ java/java-tree.h (working copy)
@@ -145,6 +145,9 @@
/* When nonzero, call a library routine to do integer divisions. */
extern int flag_use_divide_subroutine;
+/* When nonzero, use atomic builtins. */
+extern int flag_use_atomic_builtins;
+
/* When nonzero, generate code for the Boehm GC. */
extern int flag_use_boehm_gc;
Index: java/gcj.texi
===================================================================
--- java/gcj.texi (revision 150696)
+++ java/gcj.texi (working copy)
@@ -607,6 +607,13 @@
accessing an object via a reference. On other systems you won't need
this because null pointer accesses are caught automatically by the
processor.
+
+@item -fuse-atomic-builtins
+On some systems, gcc can generate code for built-in atomic operations.
+Use this option to force gcj to use these builtins when compiling Java
+code. Where this capability is present it should be automatically
+detected, so you won't usually need to use this option.
+
@end table
@c man end
z
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Java: add flag_use_atomic_builtins
2009-08-12 16:09 Java: add flag_use_atomic_builtins Andrew Haley
@ 2009-08-12 16:49 ` Joseph S. Myers
2009-08-12 16:54 ` Andrew Haley
0 siblings, 1 reply; 11+ messages in thread
From: Joseph S. Myers @ 2009-08-12 16:49 UTC (permalink / raw)
To: Andrew Haley; +Cc: java-patches, Gcc Patch List
On Wed, 12 Aug 2009, Andrew Haley wrote:
> Some targets, particularly ARM, don't have instructions for things
> such as sync_compare_and_swap. Instead, a routine in libgcc is
> used. This patch adds a new gcj option, -fuse-atomic-builtins,
> which causes gcj to use the routines in libgcc whenever atomic
> operations are needed.
Wouldn't a target hook to allow a target to declare which operations it
provides in libgcc be better than a command-line option?
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Java: add flag_use_atomic_builtins
2009-08-12 16:49 ` Joseph S. Myers
@ 2009-08-12 16:54 ` Andrew Haley
2009-08-12 16:57 ` Paolo Bonzini
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Haley @ 2009-08-12 16:54 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: java-patches, Gcc Patch List
Joseph S. Myers wrote:
> On Wed, 12 Aug 2009, Andrew Haley wrote:
>
>> Some targets, particularly ARM, don't have instructions for things
>> such as sync_compare_and_swap. Instead, a routine in libgcc is
>> used. This patch adds a new gcj option, -fuse-atomic-builtins,
>> which causes gcj to use the routines in libgcc whenever atomic
>> operations are needed.
>
> Wouldn't a target hook to allow a target to declare which operations it
> provides in libgcc be better than a command-line option?
Maybe it would. I'm happy to work with anyone to create such a
thing. What would such a hook look like, and how would a front-
end use it?
Andrew.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Java: add flag_use_atomic_builtins
2009-08-12 16:54 ` Andrew Haley
@ 2009-08-12 16:57 ` Paolo Bonzini
2009-08-12 17:05 ` Andrew Haley
0 siblings, 1 reply; 11+ messages in thread
From: Paolo Bonzini @ 2009-08-12 16:57 UTC (permalink / raw)
To: Andrew Haley; +Cc: Joseph S. Myers, java-patches, Gcc Patch List
On 08/12/2009 06:52 PM, Andrew Haley wrote:
> Joseph S. Myers wrote:
>> On Wed, 12 Aug 2009, Andrew Haley wrote:
>>
>>> Some targets, particularly ARM, don't have instructions for things
>>> such as sync_compare_and_swap. Instead, a routine in libgcc is
>>> used. This patch adds a new gcj option, -fuse-atomic-builtins,
>>> which causes gcj to use the routines in libgcc whenever atomic
>>> operations are needed.
>> Wouldn't a target hook to allow a target to declare which operations it
>> provides in libgcc be better than a command-line option?
>
> Maybe it would. I'm happy to work with anyone to create such a
> thing. What would such a hook look like, and how would a front-
> end use it?
Couldn't optabs be (re)used?
Paolo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Java: add flag_use_atomic_builtins
2009-08-12 16:57 ` Paolo Bonzini
@ 2009-08-12 17:05 ` Andrew Haley
2009-08-12 17:17 ` Andrew Haley
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Haley @ 2009-08-12 17:05 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Joseph S. Myers, java-patches, Gcc Patch List
Paolo Bonzini wrote:
> On 08/12/2009 06:52 PM, Andrew Haley wrote:
>> Joseph S. Myers wrote:
>>> On Wed, 12 Aug 2009, Andrew Haley wrote:
>>>
>>>> Some targets, particularly ARM, don't have instructions for things
>>>> such as sync_compare_and_swap. Instead, a routine in libgcc is
>>>> used. This patch adds a new gcj option, -fuse-atomic-builtins,
>>>> which causes gcj to use the routines in libgcc whenever atomic
>>>> operations are needed.
>>> Wouldn't a target hook to allow a target to declare which operations it
>>> provides in libgcc be better than a command-line option?
>>
>> Maybe it would. I'm happy to work with anyone to create such a
>> thing. What would such a hook look like, and how would a front-
>> end use it?
>
> Couldn't optabs be (re)used?
That would be nice.
Andrew.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Java: add flag_use_atomic_builtins
2009-08-12 17:05 ` Andrew Haley
@ 2009-08-12 17:17 ` Andrew Haley
2009-08-12 18:08 ` Boehm, Hans
2009-08-12 18:08 ` Paolo Bonzini
0 siblings, 2 replies; 11+ messages in thread
From: Andrew Haley @ 2009-08-12 17:17 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Joseph S. Myers, java-patches, Gcc Patch List
Andrew Haley wrote:
> Paolo Bonzini wrote:
>> On 08/12/2009 06:52 PM, Andrew Haley wrote:
>>> Joseph S. Myers wrote:
>>>> On Wed, 12 Aug 2009, Andrew Haley wrote:
>>>>
>>>>> Some targets, particularly ARM, don't have instructions for things
>>>>> such as sync_compare_and_swap. Instead, a routine in libgcc is
>>>>> used. This patch adds a new gcj option, -fuse-atomic-builtins,
>>>>> which causes gcj to use the routines in libgcc whenever atomic
>>>>> operations are needed.
>>>> Wouldn't a target hook to allow a target to declare which operations it
>>>> provides in libgcc be better than a command-line option?
>>> Maybe it would. I'm happy to work with anyone to create such a
>>> thing. What would such a hook look like, and how would a front-
>>> end use it?
>> Couldn't optabs be (re)used?
>
> That would be nice.
I guess that's just a matter of
set_optab_libfunc (sync_compare_and_swap_optab, SImode,, SImode, SImode "__sync_bool_compare_and_swap_4");
or somesuch?
Andrew.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Java: add flag_use_atomic_builtins
2009-08-12 17:17 ` Andrew Haley
2009-08-12 18:08 ` Boehm, Hans
@ 2009-08-12 18:08 ` Paolo Bonzini
1 sibling, 0 replies; 11+ messages in thread
From: Paolo Bonzini @ 2009-08-12 18:08 UTC (permalink / raw)
To: Andrew Haley; +Cc: Joseph S. Myers, java-patches, Gcc Patch List
Andrew Haley wrote:
> Andrew Haley wrote:
>> Paolo Bonzini wrote:
>>> On 08/12/2009 06:52 PM, Andrew Haley wrote:
>>>> Joseph S. Myers wrote:
>>>>> On Wed, 12 Aug 2009, Andrew Haley wrote:
>>>>>
>>>>>> Some targets, particularly ARM, don't have instructions for things
>>>>>> such as sync_compare_and_swap. Instead, a routine in libgcc is
>>>>>> used. This patch adds a new gcj option, -fuse-atomic-builtins,
>>>>>> which causes gcj to use the routines in libgcc whenever atomic
>>>>>> operations are needed.
>>>>> Wouldn't a target hook to allow a target to declare which operations it
>>>>> provides in libgcc be better than a command-line option?
>>>> Maybe it would. I'm happy to work with anyone to create such a
>>>> thing. What would such a hook look like, and how would a front-
>>>> end use it?
>>> Couldn't optabs be (re)used?
>> That would be nice.
>
> I guess that's just a matter of
>
> set_optab_libfunc (sync_compare_and_swap_optab, SImode,, SImode, SImode "__sync_bool_compare_and_swap_4");
>
> or somesuch?
Yes, that's what I was too lazy to look up. Then possibly the
middle-end needs to be taught about it rather than the front-end, I
don't know.
Paolo
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Java: add flag_use_atomic_builtins
2009-08-12 17:17 ` Andrew Haley
@ 2009-08-12 18:08 ` Boehm, Hans
2009-08-12 18:25 ` Boehm, Hans
2009-08-12 18:08 ` Paolo Bonzini
1 sibling, 1 reply; 11+ messages in thread
From: Boehm, Hans @ 2009-08-12 18:08 UTC (permalink / raw)
To: Andrew Haley, Paolo Bonzini; +Cc: Joseph S. Myers, java-patches, Gcc Patch List
At the risk of asking a stupid question, shouldn't all the code inside gcc gradually migrate towards using the C++0x (and probably C1x) atomics, which seem to be generally supported by gcc 4.4?
There are known issues with __sync (no atomic loads and stores, underspecified ordering), which is why there wasn't much of an effort topush the __sync interface into C++0x.
Hans
> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org
> [mailto:java-patches-owner@gcc.gnu.org] On Behalf Of Andrew Haley
> Sent: Wednesday, August 12, 2009 10:15 AM
> To: Paolo Bonzini
> Cc: Joseph S. Myers; java-patches@gcc.gnu.org; Gcc Patch List
> Subject: Re: Java: add flag_use_atomic_builtins
>
> Andrew Haley wrote:
> > Paolo Bonzini wrote:
> >> On 08/12/2009 06:52 PM, Andrew Haley wrote:
> >>> Joseph S. Myers wrote:
> >>>> On Wed, 12 Aug 2009, Andrew Haley wrote:
> >>>>
> >>>>> Some targets, particularly ARM, don't have instructions
> for things
> >>>>> such as sync_compare_and_swap. Instead, a routine in libgcc is
> >>>>> used. This patch adds a new gcj option, -fuse-atomic-builtins,
> >>>>> which causes gcj to use the routines in libgcc whenever atomic
> >>>>> operations are needed.
> >>>> Wouldn't a target hook to allow a target to declare which
> >>>> operations it provides in libgcc be better than a
> command-line option?
> >>> Maybe it would. I'm happy to work with anyone to create such a
> >>> thing. What would such a hook look like, and how would a
> front- end
> >>> use it?
> >> Couldn't optabs be (re)used?
> >
> > That would be nice.
>
> I guess that's just a matter of
>
> set_optab_libfunc (sync_compare_and_swap_optab, SImode,,
> SImode, SImode "__sync_bool_compare_and_swap_4");
>
> or somesuch?
>
> Andrew.
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Java: add flag_use_atomic_builtins
2009-08-12 18:08 ` Boehm, Hans
@ 2009-08-12 18:25 ` Boehm, Hans
2009-08-12 18:27 ` Richard Guenther
2009-08-12 19:00 ` David Daney
0 siblings, 2 replies; 11+ messages in thread
From: Boehm, Hans @ 2009-08-12 18:25 UTC (permalink / raw)
To: Boehm, Hans, Andrew Haley, Paolo Bonzini
Cc: Joseph S. Myers, java-patches, Gcc Patch List
[Partially replying to myself]
> From: Boehm, Hans
>
> At the risk of asking a stupid question, shouldn't all the
> code inside gcc gradually migrate towards using the C++0x
> (and probably C1x) atomics, which seem to be generally
> supported by gcc 4.4?
>
> There are known issues with __sync (no atomic loads and
> stores, underspecified ordering), which is why there wasn't
> much of an effort topush the __sync interface into C++0x.
>
> Hans
>
OK. That was largely a stupid question, since we're talking about the compiler implementation of those primitives, which presumably are shared with the atomic<T> implementation?
Hans
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Java: add flag_use_atomic_builtins
2009-08-12 18:25 ` Boehm, Hans
@ 2009-08-12 18:27 ` Richard Guenther
2009-08-12 19:00 ` David Daney
1 sibling, 0 replies; 11+ messages in thread
From: Richard Guenther @ 2009-08-12 18:27 UTC (permalink / raw)
To: Boehm, Hans
Cc: Andrew Haley, Paolo Bonzini, Joseph S. Myers, java-patches,
Gcc Patch List
On Wed, Aug 12, 2009 at 8:24 PM, Boehm, Hans<hans.boehm@hp.com> wrote:
> [Partially replying to myself]
>> From: Boehm, Hans
>>
>> At the risk of asking a stupid question, shouldn't all the
>> code inside gcc gradually migrate towards using the C++0x
>> (and probably C1x) atomics, which seem to be generally
>> supported by gcc 4.4?
>>
>> There are known issues with __sync (no atomic loads and
>> stores, underspecified ordering), which is why there wasn't
>> much of an effort topush the __sync interface into C++0x.
>>
>> Hans
>>
> OK. That was largely a stupid question, since we're talking about the compiler implementation of those primitives, which presumably are shared with the atomic<T> implementation?
I'm not aware of a proper implementation of the C++1x atomics or the memory
model for gcc.
Richard.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Java: add flag_use_atomic_builtins
2009-08-12 18:25 ` Boehm, Hans
2009-08-12 18:27 ` Richard Guenther
@ 2009-08-12 19:00 ` David Daney
1 sibling, 0 replies; 11+ messages in thread
From: David Daney @ 2009-08-12 19:00 UTC (permalink / raw)
To: Boehm, Hans
Cc: Andrew Haley, Paolo Bonzini, Joseph S. Myers, java-patches,
Gcc Patch List
Boehm, Hans wrote:
> [Partially replying to myself]
>> From: Boehm, Hans
>>
>> At the risk of asking a stupid question, shouldn't all the
>> code inside gcc gradually migrate towards using the C++0x
>> (and probably C1x) atomics, which seem to be generally
>> supported by gcc 4.4?
>>
>> There are known issues with __sync (no atomic loads and
>> stores, underspecified ordering), which is why there wasn't
>> much of an effort topush the __sync interface into C++0x.
>>
>> Hans
>>
> OK. That was largely a stupid question, since we're talking about the compiler implementation of those primitives, which presumably are shared with the atomic<T> implementation?
>
The generic implementation uses __sync*, but some individual targets
have hand coded asm blocks.
David Daney
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-08-12 19:00 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-12 16:09 Java: add flag_use_atomic_builtins Andrew Haley
2009-08-12 16:49 ` Joseph S. Myers
2009-08-12 16:54 ` Andrew Haley
2009-08-12 16:57 ` Paolo Bonzini
2009-08-12 17:05 ` Andrew Haley
2009-08-12 17:17 ` Andrew Haley
2009-08-12 18:08 ` Boehm, Hans
2009-08-12 18:25 ` Boehm, Hans
2009-08-12 18:27 ` Richard Guenther
2009-08-12 19:00 ` David Daney
2009-08-12 18:08 ` Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).