Re: RFH: optabs code in the java front end

[Andrew Haley <aph at redhat dot com>]

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.