On Tue, Nov 10, 2009 at 8:10 AM, me22 <me22.ca at gmail.com> wrote:> 2009/11/9 Kenneth Uildriks <kennethuil at gmail.com>: >> >> 1. Conversions to/from other integer types: right now, integer type >> conversions are always explicity specified as either a trunc, a sext, >> or a zext. Since the size of intp is not known at IR generation time, >> you can't know whether a conversion to/from intp truncates or extends. >> > > Now that there are arbitrary-sized integers, couldn't you zext to i256 > then trunc down again, and later let the folder simplify as > appropriate?I suppose that would work, but I wouldn't like to see two cast instructions for every conversion. Perhaps every conversion to/from intp could be represented as a zext, whether or not it actually performs an extension. Is there anything in LLVM that depends on a zext actually increasing the size of the integer?
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.
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.
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.
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.)
On Tue, Nov 10, 2009 at 8:24 AM, Kenneth Uildriks <kennethuil at
gmail.com>wrote:
> On Tue, Nov 10, 2009 at 8:10 AM, me22 <me22.ca at gmail.com> wrote:
> > 2009/11/9 Kenneth Uildriks <kennethuil at gmail.com>:
> >>
> >> 1. Conversions to/from other integer types: right now, integer
type
> >> conversions are always explicity specified as either a trunc, a
sext,
> >> or a zext. Since the size of intp is not known at IR generation
time,
> >> you can't know whether a conversion to/from intp truncates or
extends.
> >>
> >
> > Now that there are arbitrary-sized integers, couldn't you zext to
i256
> > then trunc down again, and later let the folder simplify as
> > appropriate?
>
> I suppose that would work, but I wouldn't like to see two cast
> instructions for every conversion.
>
> Perhaps every conversion to/from intp could be represented as a zext,
> whether or not it actually performs an extension. Is there anything
> in LLVM that depends on a zext actually increasing the size of the
> integer?
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
--
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091110/6ef4c865/attachment.html>
On Tue, Nov 10, 2009 at 6:10 PM, Talin <viridia at gmail.com> wrote:> 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.That's the direction I'm going in too.> > 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. > > 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.)I'm willing to spend some time on adding intp to LLVM... my front-end's standard libraries would be cleaner and more portable that way.
On Nov 10, 2009, at 4:10 PM, Talin wrote:> 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.I believe that.> 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.)With this explanation, the idea of adding a union type seems a lot more compelling to me. For the record, I'm not opposed to an intptr_t type or a union type, but the semantics have to be clean and well specified. -Chris