This is the mail archive of the 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: [tree-ssa] where to fix this?

On Tue, Jan 06, 2004 at 11:32:06AM -0700, 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.

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