This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix optimization regression in constant folder
- From: Michael Matz <matz at suse dot de>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: iant at google dot com, ebotcazou at adacore dot com, gcc-patches at gcc dot gnu dot org, richard dot guenther at gmail dot com
- Date: Mon, 1 Oct 2007 03:54:12 +0200 (CEST)
- Subject: Re: [PATCH] Fix optimization regression in constant folder
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <10710010056.AA15609@vlsi1.ultra.nyu.edu>
On Sun, 30 Sep 2007, Richard Kenner wrote:
> > Right. A type can be neither. But you were asking for sizetypes to
> > be both, and that does not make sense.
> No, the claim is that a sizetype can *act like* both and that's different.
Clearly a type can not be both at the same time, no matter how much you
want. I think the problem comes from the fact that we can use those
type predicates for different things, namely to 1) infer some knowledge
about past operations on values of that type (which in turn then might to
lead to other transformations), and 2) guide which operations we allow on
values of this type (e.g. that we have to add overflow checks or not).
>From what Eric and you told us up to now it seems you want this type to
have the following properties:
1) overflows don't occur (because you make sure that the compiler never
produces overflows on such values)
2) if overflow were to occur, then it wraps (given the first
property this is weird, but that is what you said)
3) you want to optimize based on both assumptions, i.e. that overflow
can't occur, and that the type has wrap-around
I think you need to make up your mind about the property (2) above: why
_exactly_ (meaning test situations) do you care for how overflow happens
if you already defined that it can not happen. Everything will follow
What I think you should want is that the type is simply an unsigned type,
with overflow undefined. But given the internal inconsistency in your
current wishes I can't be sure if that really solves your problems.
An unsigned type with undefined overflow does have a place in a
middle-end. A type with your current conflicting semantics does _not_
have a place in the middle-end IMHO, so it's time invested very well in
thinking hard about your exact requirements.
> You can't capture that concept with flags that talk about
> language-defined concepts such as undefined overflows or wrapping
> because sizetypes are *not* language-defined but internal.
The type flags reflect (or better are meant to reflect eventually)
properties for the middle-end type system. Languages types are required
to map to those we have (of course we can increase the set of properties
of middle-end types).
It's true that the type flags still are pretty much coming directly from
language semantics, simply because the middle-end type system is in its
infancy. But it will change in one or the other way (cross language LTO
needs that), and it would be better if it's a well thought out way.
That's why this discussion is important. So, if the middle end would give
you an unsigned, overflow undefined type, would that satisfy you (at least
when the optimization you want to happen on them, do happen then, which
also requires some example situations from you)?