This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] where to fix this?
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: law at redhat dot com
- Cc: Jan Hubicka <jh at suse dot cz>, Jan Hubicka <hubicka at ucw dot cz>,Roger Sayle <roger at eyesopen dot com>, Dale Johannesen <dalej at apple dot com>,gcc at gcc dot gnu dot org
- Date: Tue, 6 Jan 2004 11:05:38 -0800
- Subject: Re: [tree-ssa] where to fix this?
- References: <20040106162146.GI6383@kam.mff.cuni.cz> <200401061832.i06IW6QM016404@speedy.slc.redhat.com>
On Tue, Jan 06, 2004 at 11:32:06AM -0700, firstname.lastname@example.org wrote:
> This is why I said the #1 thing we have to decide is how strict do we want
> to be regarding types of operands within expressions. If we go with an
> absolutely strict system, then we need to rethink how we deal with
> type conversions in the optimizers. If we go with a looser system, then
> we need to figure out how to deal with it sanely within the checkers
> and the expanders.
The system should be precisely specified, so I think that "tight" and
"loose" are the wrong words. "loose" here would mean that the type
system from the language gets mapped into a different type system that
has fewer types, but the rules for this new type system would still be
precise and rigid. Example 1: we distinguish size and signedness of
integers, but for ILP32 int and long become the same type. Example 2:
we only distinguish size of integers, and treat signed vs unsigned
<= as separate operators. Once you have the design, everything needs
to strictly follow it, or we just get back to where we started, where
it takes years of tribal knowledge to mess with gcc internals.
If you just drift into a type system based on what people code, you're
going to have trouble.