Re: RFH: optabs code in the java front end

Re: RFH: optabs code in the java front end

[David Daney]

I don't know the answers to your specific questions, but I do know that 
java questions might get faster response if cross posted to java@ (now 
CCed).

David Daney


On 09/10/2010 03:50 PM, Steven Bosscher wrote:
> Hello,
>
> There is just one front-end file left that still has to #undef
> IN_GCC_FRONTEND, allowing the front end to include RTL headers. The
> one remaining file is java/builtins.c.
>
> In java/builtins.c there are (what appear to be) functions that
> generate code for Java builtins, and these functions look at optabs to
> decide what to emit. For example:
>
> static tree
> compareAndSwapInt_builtin (tree method_return_type ATTRIBUTE_UNUSED,
>                             tree orig_call)
> {
>    enum machine_mode mode = TYPE_MODE (int_type_node);
>    if (direct_optab_handler (sync_compare_and_swap_optab, mode)
>        != CODE_FOR_nothing
>        || flag_use_atomic_builtins)
>      {
>        tree addr, stmt;
>
>
> As a result, java/builtins.c has to include most RTL-specific headers:
>
> /* FIXME: All these headers are necessary for sync_compare_and_swap.
>     Front ends should never have to look at that.  */
> #include "rtl.h"
> #include "insn-codes.h"
> #include "expr.h"
> #include "optabs.h"
>
> I would really like to see this go away, and I would work on it if I
> had any idea what to do. I thought that the builtins java/builtins.c
> adds here, are generic GCC builtins. For example there is a definition
> of BUILT_IN_BOOL_COMPARE_AND_SWAP_4 in sync-builtins.def, so what is
> the effect of the
> "define_builtin(BUILT_IN_BOOL_COMPARE_AND_SWAP_4,...)" code in
> java/builtins.c:initialize_builtins? Does this re-define the builtin?
> I don't understand how the front-end definition of the builtin and the
> one from sync-builtins.def work together.
>
> I could use a little help here... Thoughts?
>
> Ciao!
> Steven
>

Re: RFH: optabs code in the java front end

[Andrew Haley]

On 09/10/2010 11:50 PM, Steven Bosscher wrote:

> There is just one front-end file left that still has to #undef
> IN_GCC_FRONTEND, allowing the front end to include RTL headers. The
> one remaining file is java/builtins.c.
> 
> In java/builtins.c there are (what appear to be) functions that
> generate code for Java builtins, and these functions look at optabs to
> decide what to emit. For example:
> 
> static tree
> compareAndSwapInt_builtin (tree method_return_type ATTRIBUTE_UNUSED,
>                            tree orig_call)
> {
>   enum machine_mode mode = TYPE_MODE (int_type_node);
>   if (direct_optab_handler (sync_compare_and_swap_optab, mode)
>       != CODE_FOR_nothing
>       || flag_use_atomic_builtins)
>     {
>       tree addr, stmt;
> 
> 
> As a result, java/builtins.c has to include most RTL-specific headers:
> 
> /* FIXME: All these headers are necessary for sync_compare_and_swap.
>    Front ends should never have to look at that.  */
> #include "rtl.h"
> #include "insn-codes.h"
> #include "expr.h"
> #include "optabs.h"
> 
> I would really like to see this go away, and I would work on it if I
> had any idea what to do.

The test tells us whether the back-end has atomic builtins.  If it doesn't
then we generate calls to the libgcj back end.  I really don't want gcj
to generate calls to nonexistent __compare_and_swap_4 or somesuch.

> I thought that the builtins java/builtins.c
> adds here, are generic GCC builtins. For example there is a definition
> of BUILT_IN_BOOL_COMPARE_AND_SWAP_4 in sync-builtins.def, so what is
> the effect of the
> "define_builtin(BUILT_IN_BOOL_COMPARE_AND_SWAP_4,...)" code in
> java/builtins.c:initialize_builtins? Does this re-define the builtin?
> I don't understand how the front-end definition of the builtin and the
> one from sync-builtins.def work together.

Well, the ones from sync-builtins.def have different names: otherwise
they're the same as the Java ones.

Andrew.

Re: RFH: optabs code in the java front end

[Steven Bosscher]

On Sat, Sep 11, 2010 at 8:48 PM, Andrew Haley <aph@redhat.com> wrote:
> On 09/10/2010 11:50 PM, Steven Bosscher wrote:
>
>> There is just one front-end file left that still has to #undef
>> IN_GCC_FRONTEND, allowing the front end to include RTL headers. The
>> one remaining file is java/builtins.c.
>>
>> In java/builtins.c there are (what appear to be) functions that
>> generate code for Java builtins, and these functions look at optabs to
>> decide what to emit. For example:
>>
>> static tree
>> compareAndSwapInt_builtin (tree method_return_type ATTRIBUTE_UNUSED,
>>                            tree orig_call)
>> {
>>   enum machine_mode mode = TYPE_MODE (int_type_node);
>>   if (direct_optab_handler (sync_compare_and_swap_optab, mode)
>>       != CODE_FOR_nothing
>>       || flag_use_atomic_builtins)
>>     {
>>       tree addr, stmt;
>>
>>
>> As a result, java/builtins.c has to include most RTL-specific headers:
>>
>> /* FIXME: All these headers are necessary for sync_compare_and_swap.
>>    Front ends should never have to look at that.  */
>> #include "rtl.h"
>> #include "insn-codes.h"
>> #include "expr.h"
>> #include "optabs.h"
>>
>> I would really like to see this go away, and I would work on it if I
>> had any idea what to do.
>
> The test tells us whether the back-end has atomic builtins.  If it doesn't
> then we generate calls to the libgcj back end.  I really don't want gcj
> to generate calls to nonexistent __compare_and_swap_4 or somesuch.
>
>> I thought that the builtins java/builtins.c
>> adds here, are generic GCC builtins. For example there is a definition
>> of BUILT_IN_BOOL_COMPARE_AND_SWAP_4 in sync-builtins.def, so what is
>> the effect of the
>> "define_builtin(BUILT_IN_BOOL_COMPARE_AND_SWAP_4,...)" code in
>> java/builtins.c:initialize_builtins? Does this re-define the builtin?
>> I don't understand how the front-end definition of the builtin and the
>> one from sync-builtins.def work together.
>
> Well, the ones from sync-builtins.def have different names: otherwise
> they're the same as the Java ones.

So why can't these be called instead of the Java ones? I suppose there
are libgcc versions?

Ciao!
Steven

Re: RFH: optabs code in the java front end

[Joseph S. Myers]

On Sat, 11 Sep 2010, Andrew Haley wrote:

> The test tells us whether the back-end has atomic builtins.  If it doesn't
> then we generate calls to the libgcj back end.  I really don't want gcj
> to generate calls to nonexistent __compare_and_swap_4 or somesuch.

Maybe not to nonexistent functions, but if the functions exist - say the 
kernel-assisted libgcc functions used on Linux on SH, PA and older ARM 
processors - then certainly they should be used.  So optabs are hardly the 
right thing to check; if you need to know whether this functionality is 
supported, you need a hook that will say whether there is a library 
fallback when code for __sync_* isn't generated inline.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: RFH: optabs code in the java front end

[Andrew Haley]

On 11/09/10 20:28, Steven Bosscher wrote:
> On Sat, Sep 11, 2010 at 8:48 PM, Andrew Haley <aph@redhat.com> wrote:
>> On 09/10/2010 11:50 PM, Steven Bosscher wrote:
>>
>>> There is just one front-end file left that still has to #undef
>>> IN_GCC_FRONTEND, allowing the front end to include RTL headers. The
>>> one remaining file is java/builtins.c.
>>>
>>> In java/builtins.c there are (what appear to be) functions that
>>> generate code for Java builtins, and these functions look at optabs to
>>> decide what to emit. For example:
>>>
>>> static tree
>>> compareAndSwapInt_builtin (tree method_return_type ATTRIBUTE_UNUSED,
>>>                            tree orig_call)
>>> {
>>>   enum machine_mode mode = TYPE_MODE (int_type_node);
>>>   if (direct_optab_handler (sync_compare_and_swap_optab, mode)
>>>       != CODE_FOR_nothing
>>>       || flag_use_atomic_builtins)
>>>     {
>>>       tree addr, stmt;
>>>
>>>
>>> As a result, java/builtins.c has to include most RTL-specific headers:
>>>
>>> /* FIXME: All these headers are necessary for sync_compare_and_swap.
>>>    Front ends should never have to look at that.  */
>>> #include "rtl.h"
>>> #include "insn-codes.h"
>>> #include "expr.h"
>>> #include "optabs.h"
>>>
>>> I would really like to see this go away, and I would work on it if I
>>> had any idea what to do.
>>
>> The test tells us whether the back-end has atomic builtins.  If it doesn't
>> then we generate calls to the libgcj back end.  I really don't want gcj
>> to generate calls to nonexistent __compare_and_swap_4 or somesuch.
>>
>>> I thought that the builtins java/builtins.c
>>> adds here, are generic GCC builtins. For example there is a definition
>>> of BUILT_IN_BOOL_COMPARE_AND_SWAP_4 in sync-builtins.def, so what is
>>> the effect of the
>>> "define_builtin(BUILT_IN_BOOL_COMPARE_AND_SWAP_4,...)" code in
>>> java/builtins.c:initialize_builtins? Does this re-define the builtin?
>>> I don't understand how the front-end definition of the builtin and the
>>> one from sync-builtins.def work together.
>>
>> Well, the ones from sync-builtins.def have different names: otherwise
>> they're the same as the Java ones.
> 
> So why can't these be called instead of the Java ones? I suppose there
> are libgcc versions?

On some systems they don't exist, and indeed on some systems it is even
impossible to write them because the CPU has no appropriate instructions
and the OS has no suitable calls.  On such systems libgcj has a workaround
that provides the support we need.  We can use this workaround even when
it's not possible to provide genuine atomic builtins.

Andrew.

Re: RFH: optabs code in the java front end

[Andrew Haley]

On 11/09/10 21:21, Joseph S. Myers wrote:
> On Sat, 11 Sep 2010, Andrew Haley wrote:
> 
>> The test tells us whether the back-end has atomic builtins.  If it doesn't
>> then we generate calls to the libgcj back end.  I really don't want gcj
>> to generate calls to nonexistent __compare_and_swap_4 or somesuch.
> 
> Maybe not to nonexistent functions, but if the functions exist - say the 
> kernel-assisted libgcc functions used on Linux on SH, PA and older ARM 
> processors - then certainly they should be used.  So optabs are hardly the 
> right thing to check; if you need to know whether this functionality is 
> supported, you need a hook that will say whether there is a library 
> fallback when code for __sync_* isn't generated inline.

Sure, that would be nice.  However, my first goal is correctness, so
if we end up using slower workarounds in libgcj I can live with that, but
not failure to link because of missing library routines.

In the case of ARM GNU/Linux we work around the problem with a compile-
time option, -fuse-atomic-builtins, which overrides the optabs check.

Andrew.

RE: RFH: optabs code in the java front end

[Boehm, Hans]

I'm not up on the details here.  But I want to point out that C++0x and C1x require atomic operations on all platforms, with the expectation that they will be emulated (most likely with an address-indexed table of locks) on platforms that don't provide them.  If I understand this correctly, it sounds to me like some generalization of the Java mechanism will also be needed for C++ (and eventually C).

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf
> Of Andrew Haley
> Sent: Sunday, September 12, 2010 10:08 AM
> To: Joseph S. Myers
> Cc: gcc@gcc.gnu.org; java@gcc.gnu.org
> Subject: Re: RFH: optabs code in the java front end
> 
> On 11/09/10 21:21, Joseph S. Myers wrote:
> > On Sat, 11 Sep 2010, Andrew Haley wrote:
> >
> >> The test tells us whether the back-end has atomic builtins.  If it
> doesn't
> >> then we generate calls to the libgcj back end.  I really don't want
> gcj
> >> to generate calls to nonexistent __compare_and_swap_4 or somesuch.
> >
> > Maybe not to nonexistent functions, but if the functions exist - say
> the
> > kernel-assisted libgcc functions used on Linux on SH, PA and older
> ARM
> > processors - then certainly they should be used.  So optabs are
> hardly the
> > right thing to check; if you need to know whether this functionality
> is
> > supported, you need a hook that will say whether there is a library
> > fallback when code for __sync_* isn't generated inline.
> 
> Sure, that would be nice.  However, my first goal is correctness, so
> if we end up using slower workarounds in libgcj I can live with that,
> but
> not failure to link because of missing library routines.
> 
> In the case of ARM GNU/Linux we work around the problem with a compile-
> time option, -fuse-atomic-builtins, which overrides the optabs check.
> 
> Andrew.
>