<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="">Hi David,<div class=""><br class=""></div><div class="">I had a quick look at the inttoptr/ptrtoint thing for GlobalISel and unless I am mistaken the semantic you want for such instructions do not match what the language reference says.</div><div class=""><br class=""></div><div class="">Indeed, you said that inttoptr instruction is not a no-op on your architecture, whereas the language reference says:</div><div class="">“<span style="font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">The ‘</span><tt class="literal docutils" style="font-family: Consolas, 'Deja Vu Sans Mono', 'Bitstream Vera Sans Mono', monospace; font-size: 0.95em; background-color: rgb(242, 242, 242); border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(221, 221, 221); color: rgb(51, 51, 51);"><span class="pre">inttoptr</span></tt><span style="font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">‘ instruction converts </span><tt class="literal docutils" style="font-family: Consolas, 'Deja Vu Sans Mono', 'Bitstream Vera Sans Mono', monospace; font-size: 0.95em; background-color: rgb(242, 242, 242); border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(221, 221, 221); color: rgb(51, 51, 51);"><span class="pre">value</span></tt><span style="font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class=""> to type </span><tt class="literal docutils" style="font-family: Consolas, 'Deja Vu Sans Mono', 'Bitstream Vera Sans Mono', monospace; font-size: 0.95em; background-color: rgb(242, 242, 242); border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(221, 221, 221); color: rgb(51, 51, 51);"><span class="pre">ty2</span></tt><span style="font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class=""> by applying either a zero extension or a truncation depending on the size of the integer </span><tt class="literal docutils" style="font-family: Consolas, 'Deja Vu Sans Mono', 'Bitstream Vera Sans Mono', monospace; font-size: 0.95em; background-color: rgb(242, 242, 242); border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(221, 221, 221); color: rgb(51, 51, 51);"><span class="pre">value</span></tt><span style="font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">. If </span><tt class="literal docutils" style="font-family: Consolas, 'Deja Vu Sans Mono', 'Bitstream Vera Sans Mono', monospace; font-size: 0.95em; background-color: rgb(242, 242, 242); border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(221, 221, 221); color: rgb(51, 51, 51);"><span class="pre">value</span></tt><span style="font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class=""> is <b class="">larger</b> than the size of a pointer then a <b class="">truncation</b> is done. If </span><tt class="literal docutils" style="font-family: Consolas, 'Deja Vu Sans Mono', 'Bitstream Vera Sans Mono', monospace; font-size: 0.95em; background-color: rgb(242, 242, 242); border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(221, 221, 221); color: rgb(51, 51, 51);"><span class="pre">value</span></tt><span style="font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class=""> is <b class="">smaller</b> than the size of a pointer then a <b class="">zero extension</b> is done. If they are the <b class="">same size</b>, nothing is done (</span><em style="font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px;" class=""><b class="">no-op cast</b></em><span style="font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">).</span>”</div><div class=""><br class=""></div><div class="">The bottom line is that IMHO, if you rely on inttoptr/ptrtoint instructions to do the conversion from fat pointers to plain integers you are abusing the IR.</div><div class="">I plan to stick to the LLVM IR semantic for the generic opcode of GlobalISel and thus, it does not seem useful to have INTTOPTR like nodes around.</div><div class=""><br class=""></div><div class="">For instance, AArch64 has the TBI feature to deal more efficiently with fat pointer when accessing memory and the masking operations are explicitly set in the LLVM IR and later combine with the memory accesses.</div><div class=""><br class=""></div><div class="">Anyhow, this is just a heads-up, we will see in due time what we can do here.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">-Quentin</div><div class=""><div><blockquote type="cite" class=""><div class="">On Nov 19, 2015, at 10:53 AM, David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk" class="">David.Chisnall@cl.cam.ac.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 19 Nov 2015, at 18:07, Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><blockquote type="cite" class="">On Nov 19, 2015, at 9:50 AM, David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk" class="">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br class=""><br class="">On 19 Nov 2015, at 17:49, Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">I must miss something, but I don’t get what is the problem of lower the pointer to actual integer.<br class=""></blockquote><br class="">Pointers, in our architecture, are not integers.<br class=""></blockquote><br class="">Thanks for the clarifications.<br class=""><br class="">So what you’re saying is that a inttoptr instruction is not a no-op on your architecture, is that right?<br class=""></blockquote><br class="">Correct.<br class=""><br class=""><blockquote type="cite" class="">Or it can be a no-op only if the consumer of the pointer values can be done on the pointer register bank?<br class=""></blockquote><br class="">Yes (in some compilation models, we support 64-bit integers as pointers and 256-bit / 128-bit fat pointers, with the integer values being implicitly checked against a large region identified by one of the fat pointer registers, giving a coarse-grained sandbox that can communicate with the outside world via bounded pointers).<br class=""><br class="">We currently have entirely separate fat pointer and integer register banks, though we’re investigating a mode where we’ll overlay the two on the same register file (though they’ll likely treat some things as sub-registers.<br class=""><br class="">It also means that address space casts are not a no-op for us, which I believe is something that we share with some GPU ISAs (e.g. a 32-bit [or 16-bit] local pointer cast to a 64-bit global address space is not a simple sign/zero extension and so must be handled differently to an i32 -> i64 translation)<br class=""><br class=""><blockquote type="cite" class="">Don’t know if that helps, but note that the registers are not typed, they just have size. The operations are typed.<br class=""></blockquote><br class="">That’s fine, once you’ve assigned values to register banks. The issue is ensuring that we’re not throwing away the information that we need to do that assignment in the translation from LLVM IR to the new machine IR (i.e. which values are pointers, and which address space they are in).<br class=""><br class=""><blockquote type="cite" class="">I am trying to understand the constraint to see how that would fit in the framework. That being said, anything that you could do in SDag should be possible as well in the new framework.<br class=""></blockquote><br class="">We currently add several new nodes to SDag: INTTOPTR, PTRTOINT, and PTRADD, and a new iFATPTR MVT. The last is somewhat problematic, as we really want to have iFATPTR128 and iFATPTR256 (and, potentially, iFATPTR64 for an IoT/embedded variant).<br class=""><br class="">David<br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>