This is the mail archive of the
mailing list for the GCC project.
Re: fold_convert question
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 15 Oct 2004 18:04:56 -0600 (MDT)
- Subject: Re: fold_convert question
On Fri, 15 Oct 2004, Richard Kenner wrote:
> Right now, it does nothing only if the original and resulting type
> are the same. That seems wrong to me. Shouldn't it also do nothing
> if the types are compatible?
No, fold_convert is required to be strongly type safe by the GCC
middle-end. If a function calls fold_convert (T, X), then the tree
type of the returned expression will/must always be T.
i.e. TREE_TYPE (fold_convert (T, X)) == T
Without these semantics the only way to force a tree to type T,
would be to construct either a NOP_EXPR or a CONVERT_EXPR. And
then once you think about optimization, for example if X is already
of type T, you'll understand precisely what fold_convert does,
i.e. the equivalent of "fold (build1 (NOP_EXPR, T, X))".
[Likewise calling fold on a tree of type T, must always return
a tree of type T]
Besides, the phrase "types are compatible" is purely a front-end
concept, that doesn't exist in the middle-end. If a front-end
requires type conversion with some notion of "type compatability"
it should call "convert". Once gimplified, however, the compiler's
middle-end and tree-ssa passes should only be using fold_convert.
As an Ada person, I'm sure you appreciate not having fold_convert
impose any notion of "type compatability" on gigi's trees, other
than the semantics implied by the original trees themselves.