public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: [patch] Provide a can_compare_and_swap_p target hook.
       [not found]           ` <54593352.2000700@redhat.com>
@ 2014-11-06 17:57             ` Andrew MacLeod
  2014-11-06 18:23               ` Andrew Haley
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew MacLeod @ 2014-11-06 17:57 UTC (permalink / raw)
  To: Richard Biener, Richard Henderson, gcc-patches
  Cc: Jeff Law, Andrew Haley, java

On 11/04/2014 03:13 PM, Andrew MacLeod wrote:
> >from targhooks.c:
>>> bool
>>> default_builtin_support_vector_misalignment (machine_mode mode,
>>> const_tree type, <...>)
>>>   {
>>>    if (optab_handler (movmisalign_optab, mode) != CODE_FOR_nothing)
>>>      return true;
>>>    return false;
>>> }
>>>
>>> the idea is to move all the functionality that front ends need into
>>> well
>>> defined and controlled places so we can increase the separation.  "can
>>> perform a  compare_and_swap operation" is clearly a target specific
>>> question isn't it?
>> I would rather question what is so special about java that it needs 
>> to ask that and other frontends not.  Don't we have generic atomics 
>> support now?
>>
>> Richard.
>>
> True... I don't know if this is a thing that simply predates our 
> current level of support or if it is something else that is java 
> specific for its builtins.
> Don't know enough about java to comment.
>
> aph? Looks like you wrote the originals in 2006...   Can the java CAS 
> builtins simply use our current atomic calls rather than doing their 
> own thing and querying whether the target has a sync compare and swap 
> operation?
>
> Andrew
It looks like java is deciding whether or not GCC can inline atomic 
operations or not, and if it can't, doesn't want the atomic 
operations...   which presumably means there is no dependency on 
libatomic at runtime.

A call to can_compare_and_swap_p(mode) is analogous to a compile time 
version of folding atomic_always_lock_free(mode) to a constant...   
Frankly that seems like a reasonable question for some front end to 
ask...  and elect not to emit atomic calls if so desired. (which is what 
java is doing I think)

whether it still needs to do that is a question for some java person.

Andrew


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch] Provide a can_compare_and_swap_p target hook.
  2014-11-06 17:57             ` [patch] Provide a can_compare_and_swap_p target hook Andrew MacLeod
@ 2014-11-06 18:23               ` Andrew Haley
  2014-11-06 19:05                 ` Andrew MacLeod
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Haley @ 2014-11-06 18:23 UTC (permalink / raw)
  To: Andrew MacLeod, Richard Biener, Richard Henderson, gcc-patches
  Cc: Jeff Law, java

On 11/06/2014 05:57 PM, Andrew MacLeod wrote:
> It looks like java is deciding whether or not GCC can inline atomic 
> operations or not, and if it can't, doesn't want the atomic 
> operations...   which presumably means there is no dependency on 
> libatomic at runtime.
> 
> A call to can_compare_and_swap_p(mode) is analogous to a compile time 
> version of folding atomic_always_lock_free(mode) to a constant...   
> Frankly that seems like a reasonable question for some front end to 
> ask...  and elect not to emit atomic calls if so desired. (which is what 
> java is doing I think)
> 
> whether it still needs to do that is a question for some java person.

I did it because some targets did not have library support for some
builtins, so a compile would fail with a (to a Java programmer)
baffling error message.

The Java operations certainly should use the generic builtins.

Andrew.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch] Provide a can_compare_and_swap_p target hook.
  2014-11-06 18:23               ` Andrew Haley
@ 2014-11-06 19:05                 ` Andrew MacLeod
  2014-11-07  9:31                   ` Andrew Haley
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew MacLeod @ 2014-11-06 19:05 UTC (permalink / raw)
  To: Andrew Haley, Richard Biener, Richard Henderson, gcc-patches
  Cc: Jeff Law, java

On 11/06/2014 01:23 PM, Andrew Haley wrote:
> On 11/06/2014 05:57 PM, Andrew MacLeod wrote:
>> It looks like java is deciding whether or not GCC can inline atomic
>> operations or not, and if it can't, doesn't want the atomic
>> operations...   which presumably means there is no dependency on
>> libatomic at runtime.
>>
>> A call to can_compare_and_swap_p(mode) is analogous to a compile time
>> version of folding atomic_always_lock_free(mode) to a constant...
>> Frankly that seems like a reasonable question for some front end to
>> ask...  and elect not to emit atomic calls if so desired. (which is what
>> java is doing I think)
>>
>> whether it still needs to do that is a question for some java person.
> I did it because some targets did not have library support for some
> builtins, so a compile would fail with a (to a Java programmer)
> baffling error message.
>
> The Java operations certainly should use the generic builtins.
>
>
Thanks Andrew


1) Given that the compiler *always* provides support via libatomic now 
(even if it is via locks), does that mean that VMSupportsCS8_builtin() 
should always return true?

or should we map to that a call to __atomic_always_lock_free() ? (that 
always gets folded to a true or false at compile time)  my guess is the 
latter?

2) and in compareAndSwapLong_builtin(), thre is a wonky bit:

/* 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.  */
   if (can_compare_and_swap_p (mode,
                               (flag_use_atomic_builtins
                                && GET_MODE_SIZE (mode) <= UNITS_PER_WORD)))
     <..> /* generate 8 byte CAS  */

I gather we dont need to do anything special here anymore either?     As 
an observation of inconsistency,
compareAndSwapObject_builtin  doesn't do that check before calling the 8 
byte CAS :

machine_mode mode = TYPE_MODE (ptr_type_node);
   if (can_compare_and_swap_p (mode, flag_use_atomic_builtins))
   {
     tree addr, stmt;
     enum built_in_function builtin;

     UNMARSHAL5 (orig_call);
     builtin = (POINTER_SIZE == 32
                ? BUILT_IN_SYNC_BOOL_COMPARE_AND_SWAP_4
                : BUILT_IN_SYNC_BOOL_COMPARE_AND_SWAP_8);

     addr = build_addr_sum (value_type, obj_arg, offset_arg);



3) And finally, is flag_use_atomic_builtins suppose to turn them off 
completely?  Right now it is passed in  to the second parameter of 
can_compare_and_swap_p, which really just says can we compare and swap 
without calling a libfunc..   so currently if the flag is 0, but there 
is native support, the call is generated anyway.   should that condition 
really be:

if (flag_use_atomic_builtins)
   {
    <...> /* generate atomic call */
  }


Thanks
Andrew.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch] Provide a can_compare_and_swap_p target hook.
  2014-11-06 19:05                 ` Andrew MacLeod
@ 2014-11-07  9:31                   ` Andrew Haley
  2014-11-07 13:31                     ` Andrew MacLeod
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Haley @ 2014-11-07  9:31 UTC (permalink / raw)
  To: Andrew MacLeod, Richard Biener, Richard Henderson, gcc-patches
  Cc: Jeff Law, java

On 06/11/14 19:05, Andrew MacLeod wrote:
> 
> 
> 1) Given that the compiler *always* provides support via libatomic now 
> (even if it is via locks), does that mean that VMSupportsCS8_builtin() 
> should always return true?
> 
> or should we map to that a call to __atomic_always_lock_free() ? (that 
> always gets folded to a true or false at compile time)  my guess is the 
> latter?

Perhaps so.  The problem is that some targets can't do CAS on 64-bit
doublewords.

> 2) and in compareAndSwapLong_builtin(), thre is a wonky bit:
> 
> /* 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.  */
>    if (can_compare_and_swap_p (mode,
>                                (flag_use_atomic_builtins
>                                 && GET_MODE_SIZE (mode) <= UNITS_PER_WORD)))
>      <..> /* generate 8 byte CAS  */
> 
> I gather we dont need to do anything special here anymore either?     As 
> an observation of inconsistency,
> compareAndSwapObject_builtin  doesn't do that check before calling the 8 
> byte CAS :

I believe that any machine which has 64-bit pointers and can do CAS
can do a 64-bit CAS.  I'm worried about 32-bit machines trying to do a
64-bit CAS.

> 3) And finally, is flag_use_atomic_builtins suppose to turn them off 
> completely?  Right now it is passed in  to the second parameter of 
> can_compare_and_swap_p, which really just says can we compare and swap 
> without calling a libfunc..   so currently if the flag is 0, but there 
> is native support, the call is generated anyway.   should that condition 
> really be:
> 
> if (flag_use_atomic_builtins)
>    {
>     <...> /* generate atomic call */
>   }

I'm sorry, I really can't remember.  I can't think of any reason to
want to turn off builtin support.  You have to remember that all this
was written when our support for atomic builtins was seriously flaky
and we would just punt back to the user anything we hadn't written
yet.

Andrew.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch] Provide a can_compare_and_swap_p target hook.
  2014-11-07  9:31                   ` Andrew Haley
@ 2014-11-07 13:31                     ` Andrew MacLeod
  0 siblings, 0 replies; 5+ messages in thread
From: Andrew MacLeod @ 2014-11-07 13:31 UTC (permalink / raw)
  To: Andrew Haley, Richard Biener, Richard Henderson, gcc-patches
  Cc: Jeff Law, java

On 11/07/2014 04:31 AM, Andrew Haley wrote:
> On 06/11/14 19:05, Andrew MacLeod wrote:
>>
>> 1) Given that the compiler *always* provides support via libatomic now
>> (even if it is via locks), does that mean that VMSupportsCS8_builtin()
>> should always return true?
>>
>> or should we map to that a call to __atomic_always_lock_free() ? (that
>> always gets folded to a true or false at compile time)  my guess is the
>> latter?
> Perhaps so.  The problem is that some targets can't do CAS on 64-bit
> doublewords.
with libatomic present, I believe they always can, even if it drops to a 
lock implementation.

> I'm sorry, I really can't remember.  I can't think of any reason to
> want to turn off builtin support.  You have to remember that all this
> was written when our support for atomic builtins was seriously flaky
> and we would just punt back to the user anything we hadn't written
> yet.
>
>
No worries, i cant remember why i did something last year, let along 8 
years ago :-)

I'll take a best stab and we'll see what happens :-)

Andrew

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-11-07 13:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <5458FE9C.2090409@redhat.com>
     [not found] ` <54590C19.40208@redhat.com>
     [not found]   ` <54591348.1010904@redhat.com>
     [not found]     ` <545913A4.5010400@redhat.com>
     [not found]       ` <54591B3A.8030908@redhat.com>
     [not found]         ` <70044BE8-9F38-4BDB-B73F-6E2FC9AC2629@gmail.com>
     [not found]           ` <54593352.2000700@redhat.com>
2014-11-06 17:57             ` [patch] Provide a can_compare_and_swap_p target hook Andrew MacLeod
2014-11-06 18:23               ` Andrew Haley
2014-11-06 19:05                 ` Andrew MacLeod
2014-11-07  9:31                   ` Andrew Haley
2014-11-07 13:31                     ` Andrew MacLeod

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).