<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Chris Lattner wrote:
<blockquote cite="mid:13F1ABA0-413E-4E6C-8BAB-08DE8EB9A838@apple.com"
type="cite">
<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 moz-do-not-send="true"
href="mailto:clattner@apple.com">clattner@apple.com</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex; position: static; z-index: auto;">
<div style="">
<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>
</div>
</blockquote>
<br>
To be really pedantic, a single platform may have multiple pointer
widths; I assume intptr would correspond to the width of a generic
pointer, but non-generic address spaces are not constrained in any
direction by the size of the generic address space. Of course,
non-generic address spaces have no place in portable bitcode anyway,
but I wanted to insert a note of pedantry into the conversation. :)<br>
<br>
<blockquote cite="mid:13F1ABA0-413E-4E6C-8BAB-08DE8EB9A838@apple.com"
type="cite">
<div>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex; position: static; z-index: auto;">
<div style="">
<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>
</div>
</blockquote>
<br>
We could just say that code has undefined behavior or is invalid if the
'sext', 'zext', or 'trunc' is inappropriate for the actual size of
intptr. I think this is reasonable; if the frontend emits a zext
intptr to i32, and the pointer side is i64, that *should* be invalid.
This way the optimizer gets to keep its assumptions and it becomes the
client's responsibility to ensure that its "target-neutral" bitcode
really is neutral for the range of platforms it actually cares about.
Portable code can't be truncating arbitrary pointers to some smaller
type anyway; if the client just wants to munge the bottom bits, it can
zext and trunc to and from i8/i12/whatever.<br>
<br>
John.
</body>
</html>