<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On May 22, 2018, at 8:53 AM, Aleksey Shipilev <<a href="mailto:shade@redhat.com" class="">shade@redhat.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">int64 does not look doable, because x86_64 does not let you use imm64 in test/cmp.</span><br style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>I think it's doable; you define a constant operand type for the matcher</div><div>which is 64 bits but whose value can be expressed with a 32-bit encoding.</div><div>Actually, that's what this one appears to do:</div><div><br class=""></div><div><div>   instruct loadUI2L(rRegL dst, memory mem, immL_32bits mask)</div><div class=""><div class="">     match(Set dst (AndL (ConvI2L (LoadI mem)) mask));</div></div><div class=""><br class=""></div><div class="">But the ConvI2L keeps it from being general.  I guess there is an x86</div><div class="">encoding issue with doing a true LoadL through a mask; I don't see</div><div class="">any assembler forms for masked tests except for byte (cmpb), which you</div><div class="">are filling in.  For unmasked compares there are compares of memory</div><div class="">to literal of all sizes (cmp[bwlq]).  Do we cover those in the AD file?</div><div class=""><br class=""></div><div class="">For testing a single bit, a test of any word size in memory could be</div><div class="">strength-reduced to a byte test with an appropriate offset (0..7) and</div><div class="">shifted imm8 byte constant (>>> 8*[0..7]).  Doing that would be useful</div><div class="">for some metadata bit tests, such as the upcoming Class.isValueType,</div><div class="">as well as existing stuff like Class.isInterface.  This should be doable</div><div class="">in the AD file as well.  (Any IR-level narrowing of the memory type</div><div class="">would confuse alias analysis; this should be a private decision inside</div><div class="">the encoding of one matcher rule.)</div><div class=""><br class=""></div><div class="">We could parley your in-memory bit test into those other bit tests also.</div><div class="">That would triple the complexity of your patch, so it can be done in a</div><div class="">separate change; nevertheless I'd like to see it happen.</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">And I have to ask, "what about" int16?  Do we care?  Probably not.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I prefer to ignore int16 for a time being. The current patch is almost straight-forward port from</span><br style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">current Shenandoah tree, and we are pretty sure it works reliably.</span><br style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">16-bit is pretty marginal.  byte/int/long are the important types.  But the</div><div class="">single-bit test hack (extended to an imm8 mask test) that I suggested above</div><div class="">should be applied to all sizes.</div><div class=""><br class=""></div><div class="">Point-fixes for particular code shapes are great.  Those often drive us to</div><div class="">improve optimizations not just for the particular code shapes but for some</div><div class="">reasonable superset of those shapes.  Roland's strip mining work is a good</div><div class="">example.  As we close up some holes in an optimization (load through mask</div><div class="">then test), let's think briefly about removing the remaining known holes in</div><div class="">that same optimization, to see if there is low-hanging fruit we can pick at</div><div class="">the same time.</div><div class=""><br class=""></div><div class="">Bottom line:  While you are in this code, please check for remaining holes</div><div class="">for in-memory tests against constants and against bitmasks. I think they might</div><div class="">be listed completely in this mail.  And then please file a tracking bug with your</div><div class="">findings.</div><div class=""><br class=""></div><div class="">There are lots of bits to test out there!</div><div class=""><br class=""></div><div class="">— John (who always asks for more)</div><div class=""><br class=""></div></body></html>