<div dir="ltr"><div class="markdown-here-wrapper" style=""><blockquote style="margin:1.2em 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:1.2em 0px!important">Are you primarily trying to avoid Expand being implemented as a lib call with a larger type?</p>
</blockquote>
<p style="margin:1.2em 0px!important">No - I’m stuck in this situation:</p>
<ul style="margin:1.2em 0px;padding-left:2em">
<li style="margin:0.5em 0px">8-bit addition is legal</li>
<li style="margin:0.5em 0px">16-bit addition is illegal, should expand into an add and an add with carry</li>
<li style="margin:0.5em 0px">A few operations support 16-bit operands - the 16-bit <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248)">DREGS</code> register class</li>
</ul>
<p style="margin:1.2em 0px!important">The legalizer sees that 16-bit addition should expand. It sees that there is a 16-bit register class,<br>and it sees that 16-bit values are legal. As 16-bit is legal, it does not try and expand into a smaller type (8-bit).</p>
<p style="margin:1.2em 0px!important">This causes instruction selection to fail.</p>
<p style="margin:1.2em 0px!important">I can see why you’d want <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248)">ExpandLibCall</code> to be a separate action. Our overhanging problem is that<br>the legalizer only gives very coarse-grained control over the way it legalizes values.</p>
<div title="MDH:PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+Jmd0OyBBcmUgeW91
IHByaW1hcmlseSB0cnlpbmcgdG8gYXZvaWQgRXhwYW5kIGJlaW5nIGltcGxlbWVudGVkIGFzIGEg
bGliIGNhbGwgd2l0aCBhIGxhcmdlciB0eXBlPzwvc3Bhbj48YnI+PGRpdj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOiAxMi44MDAwMDAxOTA3MzQ5cHg7Ij48YnI+PC9zcGFuPjwvZGl2PjxkaXY+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+Tm8gLSBJJ20gc3R1Y2sg
aW4gdGhpcyBzaXR1YXRpb246PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsiPiogOC1iaXQgYWRkaXRpb24gaXMgbGVn
YWw8L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAwMDAxOTA3
MzQ5cHg7Ij4qIDE2LWJpdCBhZGRpdGlvbiBpcyBpbGxlZ2FsLCBzaG91bGQgZXhwYW5kIGludG8g
YW4gYWRkIGFuZCBhbiBhZGQgd2l0aCBjYXJyeTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsiPiogQSBmZXcgb3BlcmF0aW9ucyBzdXBw
b3J0IDE2LWJpdCBvcGVyYW5kcyAtIHRoZSAxNi1iaXQgYERSRUdTYCByZWdpc3RlciBjbGFzczwv
c3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlw
eDsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAw
MDAxOTA3MzQ5cHg7Ij5UaGUgbGVnYWxpemVyIHNlZXMgdGhhdCAxNi1iaXQgYWRkaXRpb24gc2hv
dWxkIGV4cGFuZC4gSXQgc2VlcyB0aGF0IHRoZXJlIGlzIGEgMTYtYml0IHJlZ2lzdGVyIGNsYXNz
LDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDcz
NDlweDsiPmFuZCBpdCBzZWVzIHRoYXQgMTYtYml0IHZhbHVlcyBhcmUgbGVnYWwuIEFzIDE2LWJp
dCBpcyBsZWdhbCwgaXQgZG9lcyBub3QgdHJ5IGFuZCBleHBhbmQgaW50byBhIHNtYWxsZXIgdHlw
ZSAoOC1iaXQpLjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgw
MDAwMDE5MDczNDlweDsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOiAxMi44MDAwMDAxOTA3MzQ5cHg7Ij5UaGlzIGNhdXNlcyBpbnN0cnVjdGlvbiBzZWxlY3Rp
b24gdG8gZmFpbC48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMi44
MDAwMDAxOTA3MzQ5cHg7Ij48YnI+PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+SSBjYW4gc2VlIHdoeSB5b3UnZCB3YW50IGBFeHBh
bmRMaWJDYWxsYCB0byBiZSBhIHNlcGFyYXRlIGFjdGlvbi4gT3VyIG92ZXJoYW5naW5nIHByb2Js
ZW0gaXMgdGhhdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgw
MDAwMDE5MDczNDlweDsiPnRoZSBsZWdhbGl6ZXIgb25seSBnaXZlcyB2ZXJ5IGNvYXJzZS1ncmFp
bmVkIGNvbnRyb2wgb3ZlciB0aGUgd2F5IGl0IGxlZ2FsaXplcyB2YWx1ZXMuPC9zcGFuPjwvZGl2
Pg==" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0">​</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 13, 2015 at 2:14 PM, Matt Arsenault <span dir="ltr"><<a href="mailto:arsenm2@gmail.com" target="_blank">arsenm2@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Aug 12, 2015, at 10:25 AM, Dylan McKay via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><ul style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:1.2em 0px;padding-left:2em"><li style="margin:0.5em 0px"><div style="margin:0.5em 0px!important"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline;background-color:rgb(248,248,248)">Expand</code><span> </span>should always expand the node into a different pattern (such as<span> </span><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline;background-color:rgb(248,248,248)">MULHU</code><span> </span>expanding to<span> </span><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline;background-color:rgb(248,248,248)">MUL</code><span> </span>and a copy of the top half).</div></li><li style="margin:0.5em 0px"><div style="margin:0.5em 0px!important"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline;background-color:rgb(248,248,248)">Split</code><span> </span>will always split an operation into several smaller, operations (such as 128-bit addition being split into a 64-bit addition and a 64-bit addition with carry)</div></li></ul></div></blockquote></div><br></span><div>Are you primarily trying to avoid Expand being implemented as a lib call with a larger type? Are there other cases where you want to avoid a different type of expansion besides a call? Before I’ve wanted to have ExpandLibcall be a separate action from Expand, which is somewhat similar idea.</div></div></blockquote></div><br></div>