Re: S/390: Switch to TARGET_GIMPLIFY_VA_ARG_EXPR

[Roger Sayle <roger at eyesopen dot com>]

On Thu, 17 Jun 2004, Jason Merrill wrote:
> On Thu, 17 Jun 2004 07:42:31 -0600 (MDT), Roger Sayle wrote:
> >> What about a PLUS_EXPR with a pointer and an integral operand?
> >
> > Most pointer+integer additions in the middle-end convert the integer
> > to a pointer type prior to the addition
>
> ...but this is now regarded as a design flaw; it makes it hard to determine
> which operand was a pointer on targets (pa, ia64) where that's important.

This is true enough.  However until such time as this design flaw is
resolved, probably via the addition of a non-commutative PTRPLUS_EXPR,
I believe the current best practice is to type convert both operands
to the correct same type, keeping the pointer as the first operand and
the converted integer as the second.

Although there may be missed optimization opportunities, and it is
indeed hard for PA and ia64 to correctly set REG_POINTER, those platforms
currently do a reasonable job of working around the problem.  On the other
hand, there have been serious RTL expansion bugs on all platforms from
expr.c relying on the documented behaviour that the mode of an operand is
the same as the mode of the result.

Is there an open PR for this?  Or a thread that has discussed what the
preferred solution should be?  I'd be happy to investigate a patch to
resolve this issue once and for all.


I want to get the middle-end's ducks in a row before I start complaining
about the type-system abuses made by the tree-ssa optimizers:

simplify_builtin_strcmp and fold_builtin_strcmp can't yet be unified
due to contradictory type system requirements of tree-ssa-ccp vs. fold.
The problem is an optimization of "strcmp", which returns char*, into
"memcmp", which returns void*.  Tree folding requires that the folded
expression have the same type as the original, requiring a NOP_EXPR
otherwise we get a bootstrap failure in C++ from an incompatible pointer
assignment warning/error.  Incompatibly, adding this type preserving
NOP_EXPR to simplify_builtin_strcmp breaks bootstrap in tree-ssa-ccp as
placing a NOP_EXPR around a CALL_EXPR whose result isn't used isn't a
valid gimble_stmt, hence we get bootstrap failures in tree-ssa.

Something's got to give, or we should just accept the current large
scale duplication of tree constant folding machinery.  One set that
attempts to preserve types and the other that doesn't.

Roger
--