<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">I think your proposed solution is a bit of overkill for this problem, because<br>it impacts legalization of all SDNodes, when only a few are actually used<br>for pointer arithmetic.</p>
</blockquote>
<p style="margin:1.2em 0px!important">I agree with you. I do however think that it has its advantages.</p>
<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">It seems like there are some out of tree patches for handling illegal<br>pointer types.  Maybe you can work with David to get these changes<br>upstream.</p>
</blockquote>
<p style="margin:1.2em 0px!important">There are a few out of tree patches, but they all work around the problem at hand.<br>The mailing list posting you linked was in fact made by a contributor of AVR-LLVM :)</p>
<p style="margin:1.2em 0px!important">The solutions described in the posting:</p>
<ul style="margin:1.2em 0px;padding-left:2em">
<li style="margin:0.5em 0px"><p style="margin:1.2em 0px!important;margin:0.5em 0px!important">Convoluted lowering code (with custom lowering for 16-bit operations)</p>
<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">
<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;margin:0.5em 0px!important">it lowers loads and stores during combine1 (before legalization), which is way less than ideal. It also uses 32-bit frameindexes<br>(it treats the stack as 32-bit despite global pointers being 64-bit), so I don’t think that provides a>> usable template for a solution here, unfortunately.</p>
</blockquote>
</blockquote>
</li>
<li style="margin:0.5em 0px"><p style="margin:1.2em 0px!important;margin:0.5em 0px!important">Considering pointers to be of different types</p>
<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">
<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;margin:0.5em 0px!important">If it would help, one of the changes that we’ve made is to add separate PTRADD, INTTOPTR and PTRTOINT nodes to SelectionDAG, which makes it possible to keep pointer types distinct. We currently have<br>a iFATPTR type, which is not ideal - we’d like to replace this with a set of PTR32 to PTR256 types. I’d be happy to prioritise extracting these patches for upstreaming if that would be useful to others.</p>
</blockquote>
</blockquote>
</li>
</ul>
<p style="margin:1.2em 0px!important">This may not help in our situation, as 16-bit is not a native type but there are still several other operations that can be performed on 16-bit values (not just loads/stores).</p>
<p style="margin:1.2em 0px!important">This is a problem that has been encountered by several different backends, none of which have<br>found satisfactory solutions. The proposed fix would simply give a bit more power to backend<br>maintainers (although admittedly this is necessary for most targets).</p>
<p style="margin:1.2em 0px!important">Back to your previous point</p>
<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">I think your proposed solution is a bit of overkill for this problem, because<br>it impacts legalization of all SDNodes, when only a few are actually used<br>for pointer arithmetic.</p>
</blockquote>
<p style="margin:1.2em 0px!important">The case you make is very strong, as the change proposed would break<br>dozens of backends.</p>
<p style="margin:1.2em 0px!important">We could however not cause this problem - a <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)">LegalizeAction::Split</code> could be added<br>with the meaning described earlier - split an operation into several smaller operations.<br><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)">Expand</code> would continue to have its current meaning and operation - it would either split<br>or expand into different operations.</p>
<p style="margin:1.2em 0px!important">The advantage of this is that all backends could specify <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)">Expand</code> for illegal operations, but<br>targets which need to be specifically split could then use <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)">Split</code> instead.</p>
<p style="margin:1.2em 0px!important">This would:</p>
<ul style="margin:1.2em 0px;padding-left:2em">
<li style="margin:0.5em 0px">Add the micro-optimization of decreasing code paths for ISel on each node. As the number of<br>nodes can be in the tens or hundreds of thousands for a compilation, this could be fairly beneficial</li>
<li style="margin:0.5em 0px">Current backend maintainers would have the option to change their uses of <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)">Expand</code> to <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)">Split</code> where<br>appropriate in order to be more explicit</li>
<li style="margin:0.5em 0px">In the future, if <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)">Split</code> became widespread, it would be much easier to change the meaning of <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)">Expand</code> if it were to be wanted</li>
<li style="margin:0.5em 0px">Cause no breakage</li>
</ul>
<p style="margin:1.2em 0px!important">What do you think?</p>
<div title="MDH:Jmd0O8KgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+SSB0aGlu
ayB5b3VyIHByb3Bvc2VkIHNvbHV0aW9uIGlzIGEgYml0IG9mIG92ZXJraWxsIGZvciB0aGlzIHBy
b2JsZW0sIGJlY2F1c2U8L3NwYW4+PGJyIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDcz
NDlweDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsiPiZndDtp
dCBpbXBhY3RzIGxlZ2FsaXphdGlvbiBvZiBhbGwgU0ROb2Rlcywgd2hlbiBvbmx5IGEgZmV3IGFy
ZSBhY3R1YWxseSB1c2VkPC9zcGFuPjxiciBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAwMDAxOTA3
MzQ5cHg7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAwMDAxOTA3MzQ5cHg7Ij4mZ3Q7
IGZvciBwb2ludGVyIGFyaXRobWV0aWMuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1zaXplOiAxMi44
MDAwMDAxOTA3MzQ5cHg7Ij48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5
MDczNDlweDsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx
Mi44MDAwMDAxOTA3MzQ5cHg7Ij5JIGFncmVlIHdpdGggeW91LiBJIGRvIGhvd2V2ZXIgdGhpbmsg
dGhhdCBpdCBoYXMgaXRzIGFkdmFudGFnZXMuPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsiPiZndDsmbmJzcDs8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+SXQgc2VlbXMg
bGlrZSB0aGVyZSBhcmUgc29tZSBvdXQgb2YgdHJlZSBwYXRjaGVzIGZvciBoYW5kbGluZyBpbGxl
Z2FsPC9zcGFuPjwvZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlw
eDsiPiZndDsgcG9pbnRlciB0eXBlcy4mbmJzcDsgTWF5YmUgeW91IGNhbiB3b3JrIHdpdGggRGF2
aWQgdG8gZ2V0IHRoZXNlIGNoYW5nZXM8L3NwYW4+PGJyIHN0eWxlPSJmb250LXNpemU6IDEyLjgw
MDAwMDE5MDczNDlweDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlw
eDsiPiZndDsgdXBzdHJlYW0uPC9zcGFuPjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIu
ODAwMDAwMTkwNzM0OXB4OyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsiPlRoZXJlIGFyZSBhIGZldyBvdXQgb2YgdHJlZSBw
YXRjaGVzLCBidXQgdGhleSBhbGwgd29yayBhcm91bmQgdGhlIHByb2JsZW0gYXQgaGFuZC48L3Nw
YW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAwMDAxOTA3MzQ5cHg7
Ij5UaGUgbWFpbGluZyBsaXN0IHBvc3RpbmcgeW91IGxpbmtlZCB3YXMgaW4gZmFjdCBtYWRlIGJ5
IGEgY29udHJpYnV0b3Igb2YgQVZSLUxMVk0gOik8YnI+PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+PGJyPjwvc3Bhbj48L2Rpdj48
ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsiPlRoZSBzb2x1
dGlvbnMgZGVzY3JpYmVkIGluIHRoZSBwb3N0aW5nOjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsiPiogQ29udm9sdXRlZCBsb3dlcmlu
ZyBjb2RlICh3aXRoIGN1c3RvbSBsb3dlcmluZyBmb3IgMTYtYml0IG9wZXJhdGlvbnMpPC9zcGFu
PjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+
Jmd0OyZndDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyNHB4OyB0ZXh0
LWFsaWduOiBqdXN0aWZ5OyI+aXQgbG93ZXJzIGxvYWRzIGFuZCZuYnNwOzwvc3Bhbj5zdG9yZXMg
ZHVyaW5nIGNvbWJpbmUxIChiZWZvcmUgbGVnYWxpemF0aW9uKSwgd2hpY2ggaXMgd2F5IGxlc3Mg
dGhhbiBpZGVhbC4gSXQgYWxzbyB1c2VzIDMyLWJpdCBmcmFtZWluZGV4ZXM8L2Rpdj48ZGl2PiZn
dDsmZ3Q7IChpdCB0cmVhdHMgdGhlIHN0YWNrIGFzIDMyLWJpdCBkZXNwaXRlIGdsb2JhbCBwb2lu
dGVycyBiZWluZyA2NC1iaXQpLCBzbyBJIGRvbuKAmXQgdGhpbmsgdGhhdCBwcm92aWRlcyBhPGRp
dj4mZ3Q7Jmd0OyB1c2FibGUgdGVtcGxhdGUgZm9yIGEgc29sdXRpb24gaGVyZSwgdW5mb3J0dW5h
dGVseS48L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiogQ29uc2lkZXJpbmcgcG9pbnRl
cnMgdG8gYmUgb2YgZGlmZmVyZW50IHR5cGVzPC9kaXY+Jmd0OyZndDsgSWYgaXQgd291bGQgaGVs
cCwgb25lIG9mIHRoZSBjaGFuZ2VzIHRoYXQgd2XigJl2ZSBtYWRlIGlzIHRvIGFkZCBzZXBhcmF0
ZSBQVFJBREQsIElOVFRPUFRSIGFuZCBQVFJUT0lOVCBub2RlcyB0byBTZWxlY3Rpb25EQUcsIHdo
aWNoIG1ha2VzIGl0IHBvc3NpYmxlIHRvIGtlZXAgcG9pbnRlciB0eXBlcyBkaXN0aW5jdC4gV2Ug
Y3VycmVudGx5IGhhdmU8ZGl2PiZndDsmZ3Q7YSBpRkFUUFRSIHR5cGUsIHdoaWNoIGlzIG5vdCBp
ZGVhbCAtIHdl4oCZZCBsaWtlIHRvIHJlcGxhY2UgdGhpcyB3aXRoIGEgc2V0IG9mIFBUUjMyIHRv
IFBUUjI1NiB0eXBlcy4gSeKAmWQgYmUgaGFwcHkgdG8gcHJpb3JpdGlzZSBleHRyYWN0aW5nIHRo
ZXNlIHBhdGNoZXMgZm9yIHVwc3RyZWFtaW5nIGlmIHRoYXQgd291bGQgYmUgdXNlZnVsIHRvIG90
aGVycy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoaXMgbWF5IG5vdCBoZWxwIGluIG91ciBz
aXR1YXRpb24sIGFzIDE2LWJpdCBpcyBub3QgYSBuYXRpdmUgdHlwZSBidXQgdGhlcmUgYXJlIHN0
aWxsIHNldmVyYWwgb3RoZXIgb3BlcmF0aW9ucyB0aGF0IGNhbiBiZSBwZXJmb3JtZWQgb24gMTYt
Yml0IHZhbHVlcyAobm90IGp1c3QgbG9hZHMvc3RvcmVzKS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48
ZGl2PlRoaXMgaXMgYSBwcm9ibGVtIHRoYXQgaGFzIGJlZW4gZW5jb3VudGVyZWQgYnkgc2V2ZXJh
bCBkaWZmZXJlbnQgYmFja2VuZHMsIG5vbmUgb2Ygd2hpY2ggaGF2ZTwvZGl2PjxkaXY+Zm91bmQg
c2F0aXNmYWN0b3J5IHNvbHV0aW9ucy4gVGhlIHByb3Bvc2VkIGZpeCB3b3VsZCBzaW1wbHkgZ2l2
ZSBhIGJpdCBtb3JlIHBvd2VyIHRvIGJhY2tlbmQ8L2Rpdj48ZGl2Pm1haW50YWluZXJzIChhbHRo
b3VnaCBhZG1pdHRlZGx5IHRoaXMgaXMgbmVjZXNzYXJ5IGZvciBtb3N0IHRhcmdldHMpLjwvZGl2
PjxkaXY+PGJyPjwvZGl2PjxkaXY+QmFjayB0byB5b3VyIHByZXZpb3VzIHBvaW50PC9kaXY+PGRp
dj48YnI+PC9kaXY+PGRpdj4mZ3Q7Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAw
MDAwMTkwNzM0OXB4OyI+SSB0aGluayB5b3VyIHByb3Bvc2VkIHNvbHV0aW9uIGlzIGEgYml0IG9m
IG92ZXJraWxsIGZvciB0aGlzIHByb2JsZW0sIGJlY2F1c2U8L3NwYW4+PC9kaXY+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+Jmd0OyBpdCBpbXBhY3RzIGxlZ2Fs
aXphdGlvbiBvZiBhbGwgU0ROb2Rlcywgd2hlbiBvbmx5IGEgZmV3IGFyZSBhY3R1YWxseSB1c2Vk
PC9zcGFuPjxiciBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAwMDAxOTA3MzQ5cHg7Ij48c3BhbiBz
dHlsZT0iZm9udC1zaXplOiAxMi44MDAwMDAxOTA3MzQ5cHg7Ij4mZ3Q7IGZvciBwb2ludGVyIGFy
aXRobWV0aWMuPC9zcGFuPjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkw
NzM0OXB4OyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEy
LjgwMDAwMDE5MDczNDlweDsiPlRoZSBjYXNlIHlvdSBtYWtlIGlzIHZlcnkgc3Ryb25nLCBhcyB0
aGUgY2hhbmdlIHByb3Bvc2VkIHdvdWxkIGJyZWFrPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+ZG96ZW5zIG9mIGJhY2tlbmRzLjwv
c3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlw
eDsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAw
MDAxOTA3MzQ5cHg7Ij5XZSBjb3VsZCBob3dldmVyIG5vdCBjYXVzZSB0aGlzIHByb2JsZW0gLSBh
IGBMZWdhbGl6ZUFjdGlvbjo6U3BsaXRgIGNvdWxkIGJlIGFkZGVkPC9zcGFuPjwvZGl2PjxkaXY+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+d2l0aCB0aGUgbWVh
bmluZyBkZXNjcmliZWQgZWFybGllciAtIHNwbGl0IGFuIG9wZXJhdGlvbiBpbnRvIHNldmVyYWwg
c21hbGxlciBvcGVyYXRpb25zLjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNp
emU6IDEyLjgwMDAwMDE5MDczNDlweDsiPmBFeHBhbmRgIHdvdWxkIGNvbnRpbnVlIHRvIGhhdmUg
aXRzIGN1cnJlbnQgbWVhbmluZyBhbmQgb3BlcmF0aW9uIC0gaXQgd291bGQgZWl0aGVyIHNwbGl0
PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0
OXB4OyI+b3IgZXhwYW5kIGludG8gZGlmZmVyZW50IG9wZXJhdGlvbnMuPC9zcGFuPjwvZGl2Pjxk
aXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+PGJyPjwvc3Bh
bj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsi
PlRoZSBhZHZhbnRhZ2Ugb2YgdGhpcyBpcyB0aGF0IGFsbCBiYWNrZW5kcyBjb3VsZCBzcGVjaWZ5
IGBFeHBhbmRgIGZvciBpbGxlZ2FsIG9wZXJhdGlvbnMsIGJ1dDwvc3Bhbj48L2Rpdj48ZGl2Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsiPnRhcmdldHMgd2hpY2gg
bmVlZCB0byBiZSBzcGVjaWZpY2FsbHkgc3BsaXQgY291bGQgdGhlbiB1c2UgYFNwbGl0YCBpbnN0
ZWFkLjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5
MDczNDlweDsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx
Mi44MDAwMDAxOTA3MzQ5cHg7Ij5UaGlzIHdvdWxkOjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDlweDsiPiogQWRkIHRoZSBtaWNyby1vcHRp
bWl6YXRpb24gb2YgZGVjcmVhc2luZyBjb2RlIHBhdGhzIGZvciBJU2VsIG9uIGVhY2ggbm9kZS4g
QXMgdGhlIG51bWJlciBvZjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
IDEyLjgwMDAwMDE5MDczNDlweDsiPm5vZGVzIGNhbiBiZSBpbiB0aGUgdGVucyBvciBodW5kcmVk
cyBvZiB0aG91c2FuZHMgZm9yIGEgY29tcGlsYXRpb24sIHRoaXMgY291bGQgYmUgZmFpcmx5IGJl
bmVmaWNpYWw8L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAw
MDAxOTA3MzQ5cHg7Ij4qIEN1cnJlbnQgYmFja2VuZCBtYWludGFpbmVycyB3b3VsZCBoYXZlIHRo
ZSBvcHRpb24gdG8gY2hhbmdlIHRoZWlyIHVzZXMgb2YgYEV4cGFuZGAgdG8gYFNwbGl0YCB3aGVy
ZTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDcz
NDlweDsiPmFwcHJvcHJpYXRlIGluIG9yZGVyIHRvIGJlIG1vcmUgZXhwbGljaXQ8L3NwYW4+PC9k
aXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAwMDAxOTA3MzQ5cHg7Ij4qIElu
IHRoZSBmdXR1cmUsIGlmIGBTcGxpdGAgYmVjYW1lIHdpZGVzcHJlYWQsIGl0IHdvdWxkIGJlIG11
Y2ggZWFzaWVyIHRvIGNoYW5nZSB0aGUgbWVhbmluZyBvZiBgRXhwYW5kYCBpZiBpdCB3ZXJlIHRv
IGJlIHdhbnRlZDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgw
MDAwMDE5MDczNDlweDsiPiogQ2F1c2Ugbm8gYnJlYWthZ2U8L3NwYW4+PC9kaXY+PGRpdj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOiAxMi44MDAwMDAxOTA3MzQ5cHg7Ij48YnI+PC9zcGFuPjwvZGl2
PjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0OXB4OyI+V2hhdCBk
byB5b3UgdGhpbms/PC9zcGFuPjwvZGl2Pg==" 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 5:51 AM, Tom Stellard <span dir="ltr"><<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Aug 13, 2015 at 05:25:29AM +1200, Dylan McKay via llvm-dev wrote:<br>
> Hello all,<br>
><br>
> I would like to propose a large change to LLVM that I would be happy to<br>
> implement.<br>
><br>
> The instruction selection legalizer knows of three different ways to<br>
> legalize an action (ignoring an already legal action).<br>
><br>
</span>>    - Expansion<br>
>    - Promotion<br>
>    - Custom<br>
<span class="">><br>
> Expanding a node will lead to one of two things - the operation will be<br>
> split into several equivalent smaller operations (i.e. 64-bit mul => two<br>
> 32-bit multiplications), or it will be expanded into a different<br>
> operation(s) (i.e. SDIVREM => SDIV + SREM or a runtime library call).<br>
><br>
> This can be ambiguous - should a 128-bit SDIVREM be expanded into two<br>
> 64-bit SDIVREMs or a 128-bit libcall.<br>
><br>
> It would be useful for LLVM to distinguish between these two operations -<br>
> i.e. instead of LegalizeAction::Expand, we have LegalizeAction::Expand and<br>
> LegalizeAction::Split.<br>
><br>
</span>>    -<br>
<span class="">><br>
>    Expand should always expand the node into a different pattern (such as<br>
>    MULHU expanding to MUL and a copy of the top half).<br>
</span>>    -<br>
<span class="">><br>
>    Split will always split an operation into several smaller, operations<br>
>    (such as 128-bit addition being split into a 64-bit addition and a 64-bit<br>
>    addition with carry)<br>
><br>
> Full disclosure: I’m working on a backend on which the pointer type is<br>
> illegal (Atmel AVR : 8-bit microcontroller with 16-bit pointers). The<br>
> problem with the ambiguity with expand today is that LLVM implicitly<br>
> assumes that as a 16-bit register class exists, then 16-bit<br>
> addition/subtraction should exist and there is no point splitting into two<br>
> 8-bit operations.<br>
><br>
<br>
</span>I think your proposed solution is a bit of overkill for this problem, because<br>
it impacts legalization of all SDNodes, when only a few are actually used<br>
for pointer arithmetic.<br>
<br>
Take a look at this thread:<br>
<br>
<a href="http://comments.gmane.org/gmane.comp.compilers.llvm.devel/87321" rel="noreferrer" target="_blank">http://comments.gmane.org/gmane.comp.compilers.llvm.devel/87321</a><br>
<br>
It seems like there are some out of tree patches for handling illegal<br>
pointer types.  Maybe you can work with David to get these changes<br>
upstream.<br>
<br>
-Tom<br>
<span class=""><br>
> Currently we work around this by defining 16-bit pseudo instructions for<br>
> every instruction which is not properly supported. This gives us very<br>
> sub-optimal code and introduces many bugs. More detail about the problem<br>
> can be found in the old mailing list archives<br>
</span>> <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/087277.html" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/087277.html</a>>.<br>
<span class="">><br>
> I’m not sure if this requires an RFC? It would be a very large breaking<br>
> change. Perhaps a less drastic solution can be found, like leaving Expand<br>
> as it is, but also adding LegalizeAction::Split which must expand only<br>
> using smaller operations.<br>
><br>
> Again, I would be happy to work on this.<br>
><br>
> Cheers,<br>
> Dylan McKay<br>
> ​<br>
<br>
</span>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote></div><br></div>