Re: RFH: optabs code in the java front end

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

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