This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] where to fix this?
- From: law at redhat dot com
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Dale Johannesen <dalej at apple dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 06 Jan 2004 12:38:45 -0700
- Subject: Re: [tree-ssa] where to fix this?
- Reply-to: law at redhat dot com
In message <Pine.LNX.firstname.lastname@example.org>, Roger Sa
>On Tue, 6 Jan 2004 email@example.com wrote:
>> Note we can not replace the "x" inside the PLUS_EXPR with NOP_EXPR (a) sinc
>> that would create non-gimple code, nor can we replace the "x" inside the
>> PLUS_EXPR with "a" since that would create a PLUS_EXPR with mismatched
>> types (and mis-matched in a bad way since width and signedness and
>> widths of "a" and "x" are different).
>Ah ok. I'm guessing that the possible solution of allowing "no-op"
>conversion of operands in gimple would make tree-ssa much uglier.
Considerably. Though I keep pondering it.
>I also presume that other SSA-based optimizers don't encounter similar
>problems because they can represent implicit conversion of operands
>in their tree nodes directly, i.e. PLUS_EXPR (x, y) implies implicit
>conversion of "x" and "y" to the type of the result (or necessary type).
The typecasts primarily interfere with copy propagation, which is done
in a limited number of places. We have copy propagation in the dominator
optimizer, then a global version in tree-ssa-ccp.c.
For something like redundancy elimination we are primarily concerned
with the type of the result (and we assume that it is compatible with
the type of the RHS expression). We don't tend to peek at the type
of the underlying operands. However, I don't think that ultimately we
can or should rely on that holding long term -- I can certainly see a
day when we'll want to look more closely at the operands and will need
to have the optimizer know about whatever rules we build for the type
>It might be possible to consistently switch to a weakly typed semantics
>for GCC trees (and fold in particular),
The question in my mind is whether or not this is a good design decision.
I don't really know. It has certainly nice properties for the optimizers,
but even with a formal definition of what mis-matches are allowed we're
likely to run into numerous "issues".
> but there are lots of difficult
>corner cases where the types of operands aren't unambiguously defined by
>the type of the result.
Right. This has always been a major concern of mine. In fact, my concerns
in this area have always made me quite uneasy about the whole useless
type conversion stuff I added.
> Indeed even defining useless-conversion has had its own share of headaches.
>Do you know how this is handled in other production SSA-based compilers?
Unfortunately, I don't. It's less of an SSA issue and more of a general
optimization issue -- at what level are types exposed to the optimizers.