<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Nov 12, 2009, at 7:35 PM, Talin wrote:</div><blockquote type="cite">On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div style="word-wrap:break-word"><div><div class="im"><div><br></div></div></div></div></blockquote><div>There is also the issue of how constants should be represented.</div><div><br></div><div>For all current processors that I know of, an intptr will be either 32 or 64 bits. However, there may be some future processor which supports 128-bit pointers (although a system containing that much RAM or even virtual address space is hard to imagine.)</div></div></blockquote><div><br></div><div>8, 16, and 24-bit address spaces are also popular.</div><br><blockquote type="cite"><div class="gmail_quote">
<div>If we assume that i64 is the upper limit, then intptr constants can be converted to i64 until needed.</div><div><br></div><div>Some constant folding can occur if the folding wouldn't change the final result. Specifically, for any function f(x, y) where (i32)f(x, y) is the same as (i32)f((i32)x, (i32)y), it's safe to apply that function before the final size of the integer is chosen. Thus, adding two numbers (ignoring overflow), or shifting to the left should be safe to fold.</div>
<div><br></div><div>That being said, I am perfectly fine with simply disabling folding, and leaving the partial folding as a future optimization.</div></div></blockquote><div><br></div><div>How should immediates be formed? Is it valid for a ConstantInt to have intptr type? How wide would the contained APInt be? I think it would be safe to represent all constants as (signed_int_to_intptr (constantint 42)) or something.</div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div>There is also the question of whether intptrs should be allowed as *members* of vectors. I have no opinion on this, except to say that it probably only makes sense in situations where you can also have vectors of pointers.</div></div></blockquote><div><br></div><div>Vectors of pointers are not allowed. I think disallowing intptr in vectors makes perfect sense.</div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><div>Almost *all* constant folding would have to be deferred, which means you'd get big chains of constant exprs. This isn't a problem per-say, but something to be aware of.</div>
<div><br></div><div>I don't like reusing existing sext/trunc/zext/inttoptr/ptrtoint casts for intptr. I think we should introduce new operations (hopefully with better names):</div><div><br></div><div>ptr to intptr</div>
<div>intptr to ptr</div>intptr to signed int</div><div>signed int to intptr</div><div><div>intptr to unsigned int</div><div>unsigned int to intptr</div><div><br></div><div>Does that seem reasonable?</div></div></div></blockquote>
<div><br></div><div>Sure. Another option is to do away with sext/trunc/etc. and just have two cast operations for ints: sicast and uicast. sicast converts any int size to any other (with sign extension if the destination type is bigger), and uicast is the same but with zero extension.</div></div></blockquote><div><br></div><div>sext/zext/trunc are very nice for the optimizer, we should keep them. It means that the optimizer doesn't have to check that the input to a sext is bigger or smaller than the result, for example. Code that cares (e.g. instcombine) really likes this.</div><br></div>-Chris</body></html>