<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> Prep vs. PrepBR vs. Compile<BR>
<BR>
Expr.i3 documents it.<BR>
<BR>
<BR>
(*** phase 4 ****)<BR>
(* Expressions are compiled in two steps:<BR> Prep: emit any code that includes branchs or stores<BR> Compile: emit the rest of the code<BR>*)<BR>
<BR>
PROCEDURE Prep (t: T);<BR>PROCEDURE Compile (t: T);<BR>(* emits code to evaluate the expression onto the top of stack *)<BR>
<BR>
<BR>
PROCEDURE PrepLValue (t: T; traced: BOOLEAN);<BR>PROCEDURE CompileLValue (t: T; traced: BOOLEAN);<BR>(* emits code to evaluate 't's L-value into s0.A. *)<BR>
PROCEDURE CompileAddress (t: T; traced: BOOLEAN);<BR>(* emits code to evaluate 't's byte address onto the top of stack.<BR> Use PrepLValue to prep these expressions. *)<BR>
<BR>
<BR>
PROCEDURE PrepBranch (t: T; true, false: CG.Label; freq: CG.Frequency);<BR>PROCEDURE CompileBranch (t: T; true, false: CG.Label; freq: CG.Frequency);<BR>(* emits code to evaluate the expression and conditionally branch to 'true'<BR> or 'false' depending on its boolean value. 'freq' is the estimated<BR> frequency that the specified branch will be taken. *)<BR><BR>
<BR>
- Jay<BR><BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: RE: [M3devel] comparisons vs. subranges<BR>Date: Sun, 14 Mar 2010 05:01:24 +0000<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
Hm. How about elsewhere m3front?<BR>Optimizing middle end not necessarily a different package?<BR> (esp. given that m3front is already big enough to afford being organized into directories: m3front/src/middle, m3front/src/target-independent-optimizations?)<BR> <BR> <BR>Maybe elsewhere in the two files I changed? Prep or PrepBR or Compile instead of Fold?<BR> I don't understand this Prep vs. PrepBR business.<BR> I found out that "BR" stands for branch, but that doesn't explain it me.<BR> Also PrepBR and Compile look very similar.<BR> I also noticed that Fold gets called twice (I had some RTIO in it) but didn't look into why.<BR> Surely doing it in PrepBR or Compile is correct or CG.m3 is correct, reasonable, efficient, maintainable?<BR> I can see why Fold would be wrong -- allowing code to compile, with a reasonable meaning, but that isn't supposed to.<BR> <BR> <BR>Or in CG.m3, which is conceptually "the bottom" of m3front, any two adjacent pieces can be considered merged into one layer.<BR>I'll look at both of those options later.<BR> <BR> <BR>I think "subrange analysis" if done enough might yield efficiencies in real code.<BR>Though m3front might already do enough of it -- e.g. the fact that you can't modify a FOR loop index affords some efficiencies, that are probably already taken into account.<BR> <BR> <BR> - Jay<BR> <BR>
<HR id=ecxstopSpelling>
From: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: RE: [M3devel] comparisons vs. subranges<BR>Date: Sun, 14 Mar 2010 03:52:15 +0000<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
Hm. You mean, like I'm not supposed to be able to say:<BR> <BR> <BR>PROCEDURE F1(bool:BOOLEAN;a:[0..1];b:[2..3])=<BR> BEGIN<BR> CASE bool OF<BR> | (a < b) => IO.Put("true\n");<BR> | (a > b) => IO.Put("false\n");<BR> END;<BR><BR> <BR>but I can say:<BR> <BR> <BR>PROCEDURE F1(bool:BOOLEAN;a:[0..1];b:[2..3])=<BR> BEGIN<BR> CASE bool OF<BR> | (LAST([0..1]) < FIRST([2..3]) => IO.Put("true\n");<BR> | (FIRST([0..1]) > LAST([2..3])=> IO.Put("false\n");<BR> END;<BR> <BR>(I'd like to be able to say FIRST(a), etc., but I don't think it is allowed.)<BR><BR> <BR> <BR>"constants" kind of seem like an optimization themselves.<BR>Other than efficiency concerns, they could all be variables<BR>initialized by module initializers, that the frontend doesn't<BR>let you write to. Including de-optimizations like runtime<BR>allocation/sizing of arrays based on const/non-const sizes.<BR> <BR> <BR>Look at how I changed const to var already in m3core/unix, and then<BR>had to change CASE to if/elseif ladders.<BR>It's a minor matter of what the language lets you say,<BR>among various basically equivalent forms.<BR>The compiler could allow case to target non-constants.<BR>It'd just mainly be slower.<BR>There is the matter of CASE arms can't overlap, where if/elseif ladders can.<BR> Because CASE is conceptually compared all at once where if/elseif<BR> is sequential.<BR> <BR> <BR>Ok.<BR> <BR> <BR> <BR>I see a few options at least.<BR> <BR> <BR>m3middle could look basically like m3front, but with various checks like type checking removed<BR>and assumed true. This would be an arduous task of duplication.<BR> <BR>M3CG.i3 Var and Target.Int could gain the following fields (or methods):<BR> <BR> <BR> min_valid := FALSE;<BR> max_valid := FALSE;<BR> min := TInt.Zero;<BR> max := TInt.Zero;<BR> <BR> <BR>m3front could fill them in a few cases.<BR> Initially none, but then a few as they are discovered to be easy, correct, efficient.<BR> For constants, min = max value.<BR> For subranges, min/max come the type.<BR>The backends could use them (if valid) and possibly transform them.<BR>e.g. MIN(a,b) with valid min/max yields an expression<BR>where min is the min of the two mins, max is the min of the two maxes.<BR> <BR> <BR>MIN([0..1],[2..3]) < 2 => TRUE.<BR> <BR> <BR>Probably more correct would be:<BR> <BR>PROCEDURE declare_enum (xx: T; t: TypeUID; n_elts: INTEGER; s: BitSize) =<BR><BR>PROCEDURE declare_subrange (xx: T; t, domain: TypeUID;<BR> READONLY min, max: Target.Int;<BR> s: BitSize)<BR> <BR> => already exist<BR> <BR> <BR>and then <BR> <BR> <BR>PROCEDURE load (xx: T; v: Var; o: ByteOffset; t: MType; u: ZType) =<BR>PROCEDURE load_indirect (xx: T; o: ByteOffset; t: MType; u: ZType) =<BR>PROCEDURE load_integer (xx: T; t: IType; READONLY i: Target.Int) =<BR>PROCEDURE load_ordered (xx: T; t: MType; u: ZType; order: MemoryOrder) =<BR>etc.<BR> <BR> <BR>should all take an optional TypeUID.<BR> <BR> <BR>The second proposal I've thought a bit more about and it seems very easy.<BR>The last idea seems cleaner, but with possibly signifiant downside<BR>in that e.g. Word.T is not a subrange.<BR> <BR>There's also some unclarity with respect to<BR> Word.LT(expression, -1);<BR> <BR>-1 is a valid Word interpreted as a large number.<BR>One would want to be careful not to break that.<BR>I believe this is related to what you were saying, where operations <BR>are typed, not values.<BR> <BR> <BR>It could be that every operation needs min/max or typeuid (pairs<BR>of them for binary operations).<BR> <BR> <BR>Can we take a stab at something like this?<BR> <BR> <BR>This might also serve to replace some of what m3back does with constants already,<BR>since constants would fall out of subranges of length 1.<BR> <BR> <BR>Thanks,<BR> -Jay<BR><BR> <BR>
<HR id=ecxecxstopSpelling>
From: hosking@cs.purdue.edu<BR>Date: Sat, 13 Mar 2010 14:45:29 -0500<BR>To: hosking@cs.purdue.edu<BR>CC: m3devel@elegosoft.com; jay.krell@cornell.edu<BR>Subject: Re: [M3devel] comparisons vs. subranges<BR><BR>Jay,
<DIV><BR></DIV>
<DIV>I have reverted your commits because they violate the language definition. Constant folding in the front-end is there only to support ha language definition of constant expressions. Your changes violated that spec. If you want such optimisations they should be performed in the back-end, or if we ever get one, in an optimising middle-end.</DIV>
<DIV><BR></DIV>
<DIV><SPAN style="FONT-SIZE: 12px" class=ecxecxecxApple-style-span><FONT class=ecxecxecxApple-style-span color=#0000ff><FONT class=ecxecxecxApple-style-span face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxApple-style-span>Antony Hosking</SPAN></SPAN></FONT></FONT><FONT class=ecxecxecxApple-style-span face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxApple-style-span> | </SPAN></SPAN><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxApple-style-span>Associate Professor</SPAN></SPAN><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxApple-style-span> | Computer Science | Purdue University</SPAN></SPAN></FONT></SPAN></DIV>
<DIV>
<DIV><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="WORD-WRAP: break-word"><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV><FONT class=ecxecxecxApple-style-span face=GillSans-Light><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxApple-style-span>305 N. University Street | West Lafayette | IN 47907 | USA</SPAN></FONT></DIV>
<DIV><FONT class=ecxecxecxApple-style-span color=#0000ff face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxApple-style-span>Office</SPAN></SPAN></FONT><FONT class=ecxecxecxApple-style-span face=GillSans-Light><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxApple-style-span><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxApple-style-span> +1 765 494 6001 |<SPAN class=ecxecxecxApple-converted-space> </SPAN></SPAN></SPAN></FONT><FONT class=ecxecxecxApple-style-span color=#0000ff face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxApple-style-span>Mobile</SPAN></SPAN></FONT><FONT class=ecxecxecxApple-style-span face=GillSans-Light><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxApple-style-span><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxApple-style-span><SPAN class=ecxecxecxApple-converted-space> </SPAN>+1 765 427 5484</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=ecxecxecxApple-style-span face=GillSans-Light><BR class=ecxecxecxkhtml-block-placeholder></FONT></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><BR class=ecxecxecxApple-interchange-newline></SPAN></DIV></SPAN></SPAN><BR class=ecxecxecxApple-interchange-newline></DIV><BR>
<DIV>
<DIV>On 13 Mar 2010, at 14:23, Tony Hosking wrote:</DIV><BR class=ecxecxecxApple-interchange-newline>
<BLOCKQUOTE>
<DIV style="WORD-WRAP: break-word">
<DIV><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="WORD-WRAP: break-word"><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV><SPAN style="FONT-SIZE: medium" class=ecxecxecxApple-style-span>On 13 Mar 2010, at 13:26, Jay K wrote:</SPAN></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></SPAN></DIV>
<DIV><BR class=ecxecxecxApple-interchange-newline>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxhmmessage>Tony these are simple target-independent optimizations. I would dislike for each backend to do target-independent optimizations. Where can we put those? The front end currently does several. For example, operations on sets that fit in an integer. Division by powers of 2, Unrolling comparisons of records and sets (at least up to a certain size), removing runtime operations that are known to violate subranges (e.g. in insert/extract), occasional constant folding (in the same functions I modified), etc.<BR> <BR> <BR>What is the point of these functions Fold?<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>So that constants can be manipulated as first-class values in the language. See <A href="http://www.cs.purdue.edu/homes/hosking/m3/reference/constexpr.html">http://www.cs.purdue.edu/homes/hosking/m3/reference/constexpr.html</A>. There are many places where a compile-time constant expression is required. Fold is *not* intended for performing optimisations.</DIV><BR>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxhmmessage>Why does it have these various "cost" computations?<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Which cost computations are you referring to?</DIV><BR>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxhmmessage>Granted, they are rough.<BR> <BR> <BR>Should we beef up m3middle?<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>That might be the place... but ad hoc add-ons to m3front like you have been leaning towards are probably not the right place. Designing a reasonable place for all of these optimisations will take effort. I don't want to see us degrading the maintainability of m3front with gratuitous optimisations of dubious value.</DIV><BR>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxhmmessage>m3back doesn't optimize comparisons to constants, and a *lot* of what it does is target-independent.<BR>It would be nice to factor it better so that x86-independent code is not in files with "x86" in their name.<BR>It'd be nice to extend it to AMD64 for example (which is why I was worrying about my notions of "TypeIs64" and multiplying register counts times 4 to get byte counts, etc..) and maybe even to Sparc, PPC, ARM, etc.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Designing a decent optimising middle-end takes significant time and effort, and will require more thought.</DIV><BR>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxhmmessage> m3back is correct or extremely close to correct as far as I know.<BR>It is missing atomic operations for 8, 16, 64 bit operands.<BR></DIV></SPAN></BLOCKQUOTE>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxhmmessage> (PPC32 seems unable to support 64bit atomics btw.)<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Correct.</DIV><BR>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxhmmessage>I have to test the subrange stuff for 64bit operands. It might work, but I think optimizations are missing there as well.<BR> <BR> <BR>I'd also like to maybe inline more operations..and I was thinking about implementing inlining in general. It might not be so difficult.<BR> <BR> <BR> - Jay<BR><BR> <BR>
<HR id=ecxecxecxstopSpelling>
From:<SPAN class=ecxecxecxApple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>Date: Sat, 13 Mar 2010 13:03:18 -0500<BR>To:<SPAN class=ecxecxecxApple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>CC:<SPAN class=ecxecxecxApple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>Subject: Re: [M3devel] comparisons vs. subranges<BR><BR>Jay,
<DIV><BR></DIV>
<DIV>I am disturbed that you are inserting optimisations into the front-end that don't really belong there. The front-end is responsible for semantics and not optimisation. It was never designed to be an optimising compiler. There are better ways to go about working in optimisation, but I would hate to muddy the waters of the front-end the way you seem to intend. Let's not go down this path until there is consensus! One approach would involve communicating more information to the "back"-ends (actually, the gcc back-end should be considered a middle-end from the global perspective of optimising compilers). For example, the back-ends gets very little in the way of type information (as you note w.r. to CARDINAL). In any case, I suggest that you not obsess about performance right now but simply concentrate on correctness in your backend.</DIV>
<DIV><BR>
<DIV><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span>
<DIV style="WORD-WRAP: break-word"><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span>
<DIV><FONT class=ecxecxecxecxApple-style-span color=#0000ff><FONT class=ecxecxecxecxApple-style-span face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxecxApple-style-span>Antony Hosking</SPAN></SPAN></FONT></FONT><FONT class=ecxecxecxecxApple-style-span face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxecxApple-style-span><SPAN class=ecxecxecxecxApple-converted-space> </SPAN>|<SPAN class=ecxecxecxecxApple-converted-space> </SPAN></SPAN></SPAN><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxecxApple-style-span>Associate Professor</SPAN></SPAN><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxecxecxecxApple-style-span> | Computer Science | Purdue University</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=ecxecxecxecxApple-style-span face=GillSans-Light><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxecxApple-style-span>305 N. University Street | West Lafayette | IN 47907 | USA</SPAN></FONT></DIV>
<DIV><FONT class=ecxecxecxecxApple-style-span color=#0000ff face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxecxApple-style-span>Office</SPAN></SPAN></FONT><FONT class=ecxecxecxecxApple-style-span face=GillSans-Light><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxecxApple-style-span><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxecxApple-style-span> +1 765 494 6001 |<SPAN class=ecxecxecxecxApple-converted-space> </SPAN></SPAN></SPAN></FONT><FONT class=ecxecxecxecxApple-style-span color=#0000ff face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxecxecxecxApple-style-span>Mobile</SPAN></SPAN></FONT><FONT class=ecxecxecxecxApple-style-span face=GillSans-Light><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxecxApple-style-span><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxecxecxecxApple-style-span><SPAN class=ecxecxecxecxApple-converted-space> </SPAN>+1 765 427 5484</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=ecxecxecxecxApple-style-span face=GillSans-Light><BR class=ecxecxecxecxkhtml-block-placeholder></FONT></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><BR class=ecxecxecxecxApple-interchange-newline></SPAN></DIV></SPAN></SPAN><BR class=ecxecxecxecxApple-interchange-newline></DIV><BR>
<DIV>
<DIV>On 13 Mar 2010, at 05:19, Jay K wrote:</DIV><BR class=ecxecxecxecxApple-interchange-newline>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxecxecxecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxecxecxecxhmmessage><*UNUSED*>PROCEDURE CardinalGE0(a:CARDINAL):BOOLEAN=BEGIN RETURN a>=0; END CardinalGE0;<BR><*UNUSED*>PROCEDURE CardinalEQN1(a:CARDINAL):BOOLEAN=BEGIN RETURN a=-1; END CardinalEQN1;<BR><BR> <BR>Seems to me, the front end should notice these.<BR>The first should always be TRUE.<BR> And possibly, possibly warn.<BR>The second should always be FALSE.<BR> And possibly, possibly warn.<BR> <BR>"Generic" programming often hits this sort of thing though, a good reason not to warn.<BR>Programmer might also be working with existing code and have changed INTEGER to CARDINAL.<BR> Or be defending against future maintainers changing CARDINAL to INTEGER.<BR> <BR> <BR>The backend isn't give enough information, because CARDINAL = INTEGER as far<BR>as it is told. Due to the half range of CARDINAL and LONGCARD, that isn't wrong.<BR>The only way to get unsigned types is to use ADDRESS from what I see.<BR> <BR> <BR> - Jay<BR><BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></DIV></DIV></SPAN><BR class=ecxecxecxApple-interchange-newline></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></DIV><BR></DIV> </body>
</html>