Re: [tree-ssa] where to fix this?

[Roger Sayle <roger at eyesopen dot com>]

On Tue, 6 Jan 2004 law@redhat.com wrote:
> Note we can not replace the "x" inside the PLUS_EXPR with NOP_EXPR (a) since
> 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.
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).

I see the historical mismatch between the existing design and semantics
of GCC's trees, and the ideal representation for SSA work.

It might be possible to consistently switch to a weakly typed semantics
for GCC trees (and fold in particular), but there are lots of difficult
corner cases where the types of operands aren't unambiguously defined by
the type of the result.  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?
Its the sort of technical detail that most academic papers don't mention.

Roger
--