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]
Other format: [Raw text]

Re: [PATCH] Tree SRA and atomicity/volatility


> I disagree.  We have a defect for Ada and Ada happens to require certain
> semantics on a for now unspecified middle-end construct.  It is perfectly
> reasonable to require, that upon fixing this defect, the interface between
> the frontend and middle-end is specified where it relates to that defect.

I disagree with your disagreement. :-)  I took great care of not dragging the 
discussion towards the problem of the semantics of "volatile", my patch 
doesn't rely on it, the bug I pointed out in the Tree-SRA pass is not 
directly related to it, but rather to how TREE_SIDE_EFFECTS is honored.

To recap, we have:

/* Scalarize a LDST.  To recap, this is an assignment between one scalarizable
   reference ELT and one non-scalarizable reference OTHER.  IS_OUTPUT is true
   if ELT is on the left-hand side.  */

static void
scalarize_ldst (struct sra_elt *elt, tree other,
                block_stmt_iterator *bsi, bool is_output)
{
  /* Shouldn't have gotten called for a scalar.  */
  gcc_assert (!elt->replacement);

  if (elt->use_block_copy)
    {
      /* Since ELT is not fully instantiated, we have to leave the
         block copy in place.  Treat this as a USE.  */
      scalarize_use (elt, NULL, bsi, is_output, false);
    }
  else
    {
      /* The interesting case is when ELT is fully instantiated.  In this
         case we can have each element stored/loaded directly to/from the
         corresponding slot in OTHER.  This avoids a block copy.  */


I claim that the last comment (and the code below it) violates the perfectly 
well defined TREE_SIDE_EFFECTS flag of the middle-end if it happens to be set
on OTHER because it will generate multiple instances of OTHER out of 1.

That's all.  That the discussion has drifted towards the problem of the 
semantics of "volatile" is unfortunate and should not blur the issue.

-- 
Eric Botcazou


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