This is the mail archive of the 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: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c

In message <>, Jason Merrill writes:
 >> Also, don't we recognize functions whose calls can be elided if they're
 >> called with the same arguments repeatedly?  (I forget the technical term
 >> :)
 >"pure".  Not yet, because of TREE_SIDE_EFFECTS.  Perhaps we shouldn't set
 >TREE_SIDE_EFFECTS on calls to pure functions.
This appears to be pretty easy.  We don't necessarily want to do this 
in the front-end since  when we compile functions we record certain
meta-data such as const/pure.  So if we've compiled function X and
determined it's pure we can use that information when X is called
later in some other function within the same compilation unit.

So what I've done is twiddle the bit in the gimplifier.  It's exposed a
few issues:

  A bug when we build the CFG (see thread about gimplifying java, the
  same problem has been tickled there).  Basically when we have
  empty statements at the tail of a LOOP, we lose some edges.

  A bug in the tree-inliner -- when we inline a call to a function
  with TREE_SIDE_EFFECTS clear, the BIND_EXPR for the inlined
  copy also has TREE_SIDE_EFFECTS clear -- which isn't right since
  the inlined copy may have interesting side effects once inlined.

  operand_equal_p always returned false for CALL_EXPRs.  It's pretty
  simple to extend it to verify the operands of the CALL_EXPRs
  are equal.


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