<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
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>
Why does it have these various "cost" computations?<BR>
Granted, they are rough.<BR>
<BR>
<BR>
Should we beef up m3middle?<BR>
<BR>
<BR>
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>
<BR>
<BR>
<BR>
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>
(PPC32 seems unable to support 64bit atomics btw.)<BR>
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=stopSpelling>
From: hosking@cs.purdue.edu<BR>Date: Sat, 13 Mar 2010 13:03:18 -0500<BR>To: jay.krell@cornell.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] comparisons vs. subranges<BR><BR><BASE>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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-style-span>
<DIV><FONT class=ecxApple-style-span color=#0000ff><FONT class=ecxApple-style-span face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxApple-style-span>Antony Hosking</SPAN></SPAN></FONT></FONT><FONT class=ecxApple-style-span face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxApple-style-span><SPAN class=ecxApple-converted-space> </SPAN>|<SPAN class=ecxApple-converted-space> </SPAN></SPAN></SPAN><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxApple-style-span>Associate Professor</SPAN></SPAN><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'" class=ecxApple-style-span> | Computer Science | Purdue University</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=ecxApple-style-span face=GillSans-Light><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxApple-style-span>305 N. University Street | West Lafayette | IN 47907 | USA</SPAN></FONT></DIV>
<DIV><FONT class=ecxApple-style-span color=#0000ff face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxApple-style-span>Office</SPAN></SPAN></FONT><FONT class=ecxApple-style-span face=GillSans-Light><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxApple-style-span><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxApple-style-span> +1 765 494 6001 |<SPAN class=ecxApple-converted-space> </SPAN></SPAN></SPAN></FONT><FONT class=ecxApple-style-span color=#0000ff face="Gill Sans"><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxApple-style-span><SPAN style="FONT-FAMILY: 'Gill Sans'; COLOR: rgb(0,0,255)" class=ecxApple-style-span>Mobile</SPAN></SPAN></FONT><FONT class=ecxApple-style-span face=GillSans-Light><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxApple-style-span><SPAN style="FONT-FAMILY: GillSans-Light" class=ecxApple-style-span><SPAN class=ecxApple-converted-space> </SPAN>+1 765 427 5484</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=ecxApple-style-span face=GillSans-Light><BR class=ecxkhtml-block-placeholder></FONT></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><BR class=ecxApple-interchange-newline></SPAN></DIV></SPAN></SPAN><BR class=ecxApple-interchange-newline></DIV><BR>
<DIV>
<DIV>On 13 Mar 2010, at 05:19, Jay K wrote:</DIV><BR class=ecxApple-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=ecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxhmmessage><*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> </body>
</html>