This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fold_convert question


Doh!  I sent my response to the wrong list...


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.

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]