This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Eliminating Assembler Already Defined Messages for JavaLibrary


>>>>> "Per" == Per Bothner <per@bothner.com> writes:

    Per> The problem involves a block created by expand_fixup.  This
    Per> needs to be inserted somehow into the block structure - but
    Per> where?  Some complicating factors:

Right.  Globally, I think that expand_fixup has no business doing
this.  All tree structure should be created by the front-end; that
tree->RTL conversion is generating a BLOCK is rather grotesque -- but
I never got around to figuring out how to avoid that.

    Per> * cfun->x_whole_function_mode_p is not set.  It perhaps
    Per> should be (when compiling from source).  However, the Java

Yes, I think it should be.  As per the documentation:

  /* Nonzero if this function is being processed in function-at-a-time
     mode.  In other words, if all tree structure for this function,
     including the BLOCK tree, is created before RTL generation
     commences.  */

I believe this is true for the Java front-end.

    Per> * jc1 uses a pun where the BLOCK_SUBBLOCKS field of a block
    Per> is used for the BLOCK_EXPR_BODY of a block (i.e. the "body"
    Per> expression of a block, typically a OCMPOUND_EXPR).  The
    Per> BLOCK_EXPR_BODY is used after parsing and up until
    Per> expand_expr; BLOCK_SUBBLOCKS field needs to be correct at
    Per> final.  I don't know if this is an issue, but it could be a
    Per> contributing complicating factor.

Indeed.  This is probably a bad idea; I would suggest using the
TREE_TYPE of the block instead, perhaps -- that is (I think) unused
for a BLOCK.  If so, we should document in tree.def that this field is
free for use by front-ends.

    Per> So before we try to hack together a solution, we need to
    Per> understand / agree on some things:

    Per> (1) is setting x_whole_function_mode_p to 1 the Right Think
    Per> to do?

I think so.

    Per> (2) Given that we have a tree of BLOCK nodes created by the
    Per> front end, when expand_fixup creates a block, where should it
    Per> go?  The code for when cfun->x_whole_function_mode_p is true
    Per> is this: BLOCK_CHAIN (block) = BLOCK_CHAIN (DECL_INITIAL
    Per> (current_function_decl)); BLOCK_CHAIN (DECL_INITIAL
    Per> (current_function_decl)) = block; This doesn't work, because
    Per> DECL_INITIAL hasn't been set yet, but that can be fixed.

That's a tricky bit of logic -- but I think it's correct.  Basically,
it shouldn't matter where the new BLOCK goes because reorder_blocks is
supposed to make a nice block-tree out of what's actually in the
instruction stream.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]