I realize that most users of LLVM aren't affected by this, because most frontends aren't target-neutral, and thus know in advance how big a pointer is. At least, that's my impression.<br><br>In my case, I've been attempting to build a target-neutral frontend. In my tool chain, the target is specified at link time, not at compile time. Among other things, that means that the same IR file can be used for multiple targets.<br>

<br>What strikes me is how tantalizingly close LLVM comes to being able to do this. I am surprised, for example, that I can general all of the DWARF debugging structures without ever having to choose a target machine. Most things can be done quite easily without knowing the exact size of a pointer. When it comes to being able to "generate once, run anywhere", LLVM is like 99.5% of the way there. Which makes that last remaining .5% particularly vexing.<br>

<br>There's only a tiny handful of fairly esoteric cases which require selecting a target before you generate IR. Unfortunately, the "pointer the same size as an int" is one of these rare cases -  it is something that is very painful to try and work around. (A similar esoteric use case is: "which of the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the union problem.)<br>

<br><div class="gmail_quote">On Tue, Nov 10, 2009 at 8:24 AM, Kenneth Uildriks <span dir="ltr"><<a href="mailto:kennethuil@gmail.com">kennethuil@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">On Tue, Nov 10, 2009 at 8:10 AM, me22 <<a href="http://me22.ca" target="_blank">me22.ca</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>> wrote:<br>
> 2009/11/9 Kenneth Uildriks <<a href="mailto:kennethuil@gmail.com">kennethuil@gmail.com</a>>:<br>
>><br>
>> 1. Conversions to/from other integer types: right now, integer type<br>
>> conversions are always explicity specified as either a trunc, a sext,<br>
>> or a zext.  Since the size of intp is not known at IR generation time,<br>
>> you can't know whether a conversion to/from intp truncates or extends.<br>
>><br>
><br>
> Now that there are arbitrary-sized integers, couldn't you zext to i256<br>
> then trunc down again, and later let the folder simplify as<br>
> appropriate?<br>
<br>
</div>I suppose that would work, but I wouldn't like to see two cast<br>
instructions for every conversion.<br>
<br>
Perhaps every conversion to/from intp could be represented as a zext,<br>
whether or not it actually performs an extension.  Is there anything<br>
in LLVM that depends on a zext actually increasing the size of the<br>
integer?<br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>