This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: fold() and target-specific macros
- From: Roger Sayle <roger at eyesopen dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 14 Aug 2004 07:44:10 -0600 (MDT)
- Subject: Re: fold() and target-specific macros
On Sat, 14 Aug 2004, Andrew Haley wrote:
> We've been running into a problem where the Java bytecode we generate
> from Java source is different on different targets. Given that
> there's only one Java virtual machine, this is odd. :-)
>
> It's stuff like the code I've attached, which does folding based on
> the characteristics of the back end, in particular BITS_PER_WORD.
Would anyone object, in this particular case, to removing the constant
folding optimization?
(int) (a ? b : c) -> a ? (int)b : (int)c"
I agree with Andrew that it may be a reasonable goal to keep constant
folding as target-independent as possible (although ultimately that may
be impossible), not only for JVM bytecode but also for our tree-ssa
optimizers which ideally should produce similar results on different
platforms.
In this particular example, we often both increase code size and
inhibit if-conversion with an optimization which is probably undone
by GCC's aggressive cross-jumping. Of course, if "b" or "c" are a
memory location we loose the ability to combine the conversion with
the memory loads on platforms that support it.
Perhaps this requires some benchmarking.
My provisional recommendation would be:
> if ((code == NOP_EXPR || code == CONVERT_EXPR
> || code == NON_LVALUE_EXPR)
> && TREE_CODE (tem) == COND_EXPR
> && TREE_CODE (TREE_OPERAND (tem, 1)) == code
> && TREE_CODE (TREE_OPERAND (tem, 2)) == code
> && ! VOID_TYPE_P (TREE_OPERAND (tem, 1))
> && ! VOID_TYPE_P (TREE_OPERAND (tem, 2))
> && (TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 1), 0))
> - == TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 2), 0)))
> + == TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 2), 0))))
> - && ! (INTEGRAL_TYPE_P (TREE_TYPE (tem))
> - && (INTEGRAL_TYPE_P
> - (TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 1), 0))))
> - && TYPE_PRECISION (TREE_TYPE (tem)) <= BITS_PER_WORD))
> tem = build1 (code, type,
> build3 (COND_EXPR,
> TREE_TYPE (TREE_OPERAND
> (TREE_OPERAND (tem, 1), 0)),
> TREE_OPERAND (tem, 0),
> TREE_OPERAND (TREE_OPERAND (tem, 1), 0),
> TREE_OPERAND (TREE_OPERAND (tem, 2), 0)));
>
Sorry, that this doesn't help any of the other instances or define a
policy other than that each optimization may need to be fixed differently.
Generally, I'd prefer a new flag_target_vm than reuse flag_syntax_only for
a slightly different purpose. And in preference to that I'd prefer moving
such target-specific optimizations to RTL expansion if possible.
Thoughts?
Roger
--