similar to: [LLVMdev] Proposal: intp type

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

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

On 10 Nov., 15:10, me22 <me22... at gmail.com> wrote: > 2009/11/9 Kenneth Uildriks <kenneth... 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

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

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

On Wed, Nov 11, 2009 at 2:10 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Kenneth Uildriks wrote: >> >> 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

Kenneth Uildriks wrote: > 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

I've asked for this as well. A workaround that I have considered, but haven't had time to explore yet, is to actually store such integers as pointers, and then bitcast to int64 to do actual math operations and GEPs. While this might sound inefficient on 32-bit platforms, I believe that LLVM's optimizers can take notice of the fact that you aren't using the upper bits and

On Wed, Nov 11, 2009 at 11:11 AM, Chris Lattner <clattner at apple.com> wrote: > 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. > > >

On Nov 12, 2009, at 11:29 AM, Talin wrote: > > Well, as far as intp goes (or iptr if you prefer - the naming > convention in LLVM is i<size>) How about "intptr". > here's what I would expect: > General rule #1: If an instruction accepts both i32 and i64, then it > should accept iptr as well. If it only accepts i32, then it can > continue to only

Kenneth Uildriks wrote: > On Wed, Nov 11, 2009 at 2:10 PM, Nick Lewycky <nicholas at mxc.ca> wrote: >> Kenneth Uildriks wrote: >>> 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

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

On Nov 12, 2009, at 11:29 PM, John McCall wrote: >> 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. > > We could just say that code has undefined

Chris Lattner wrote: > On Nov 12, 2009, at 7:35 PM, Talin wrote: >> On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <clattner at apple.com >> <mailto:clattner at apple.com>> wrote: >> >> >> There is also the issue of how constants should be represented. >> >> For all current processors that I know of, an intptr will be either >> 32 or

John McCall wrote: > I didn't realize that an identity zext was actually invalid IR. That > seems like it probably causes more trouble than it's worth. > > Anyway, I suspect the question is whether you would rather break these > invariants (which are probably not critical for most optimizations) or > slowly accumulate duplicate code paths in every pass that looks at

On Nov 12, 2009, at 7:35 PM, Talin wrote: > On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <clattner at apple.com> > wrote: > > There is also the issue of how constants should be represented. > > 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

On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 12, 2009, at 11:29 AM, Talin wrote: > > > Well, as far as intp goes (or iptr if you prefer - the naming convention in > LLVM is i<size>) > > > How about "intptr". > > here's what I would expect: > > - General rule #1: If an instruction accepts

Chris Lattner wrote: > On Nov 12, 2009, at 11:29 PM, John McCall wrote: >>> 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. >>

I've been playing around with LLVM to write a backend for a rather "simple" (co-)processor. Assume that only three arithmetic instructions exist: ADD mod N, SUB mod N and MUL mod N. The modulus N is programmable and stored in a register. No ordinary arithmetic instructions are available. The word size is 256-bit. In other words, the following function, b + c mod N, corresponds to

Hi, My personal opinion: Just to be sure I understand what you're considering: you want to write a backend that will produce optimized machine code for a device with modular arithmetic instructions (not simulate such a device on a standard CPU)? In which case, won't the same assumptions that are embodied in the transformations for the case of unsigned 2's complement arithmetic (in