This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR19100: truthvalue_conversion vs. TREE_CONSTANT_OVERFLOW
- From: Roger Sayle <roger at eyesopen dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 2 Jan 2005 06:03:33 -0700 (MST)
- Subject: Re: [PATCH] PR19100: truthvalue_conversion vs. TREE_CONSTANT_OVERFLOW
On Tue, 21 Dec 2004, Mark Mitchell wrote:
> Roger Sayle wrote:
> > And in the Boolean comparison cases, we were destructively modifying
> > the tree in-place (which in the middle-end is generally considered a
> > bad thing).
> Have you measured the memory impact of this change?
My apologies for the delay, but I've now completed the requested analysis
of this patch's memory impact. Out of the 1,403,584 calls to
c_common_thruthvalue_conversion with a comparison operator in stage2,
stage3 and the libraries of a full "make bootstrap" on i686-pc-linux-gnu,
1,402,453 (or 99.92%) already have a TREE_TYPE of truthvalue_type_node.
This makes sense as these nodes should typically be created with this
type in the C/C++ front-ends, and it's type should be preserved during
middle-end transformations. The most common exceptions include things
like __builtin_isgreater where the comparison result (and therefore
the tree node) still have type "int" in C++ rather than "bool", etc.
So the actual increase in memory usage is negligible (1131 tree nodes
in a bootstrap), but this also helps explain why this long standing
bug of destructively modifying it's argument hasn't yet caused any
problems (that we're aware of).