Re: RFH: optabs code in the java front end

[Andrew Haley <aph at redhat dot com>]

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.