RFH: optabs code in the java front end

Sat Sep 11 19:28:00 GMT 2010

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