similar to: [LLVMdev] Proposal: intp type

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Proposal: intp type"

2009 Nov 10
0
[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
2009 Nov 10
3
[LLVMdev] Proposal: intp type
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
2009 Nov 11
1
[LLVMdev] Proposal: intp type
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
2009 Nov 11
0
[LLVMdev] Proposal: intp type
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
2009 Nov 11
4
[LLVMdev] Proposal: intp type
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
2009 Nov 11
2
[LLVMdev] Proposal: intp type
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
2009 Nov 11
0
[LLVMdev] Proposal: intp type
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
2009 Nov 10
0
[LLVMdev] Proposal: intp type
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
2009 Nov 12
0
[LLVMdev] Proposal: intp type
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. > > >
2009 Nov 13
6
[LLVMdev] Proposal: intp type
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
2009 Nov 11
0
[LLVMdev] Proposal: intp type
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
2009 Nov 11
4
[LLVMdev] Proposal: intp type
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
2009 Nov 13
2
[LLVMdev] Proposal: intp type
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
2009 Nov 13
0
[LLVMdev] Proposal: intp type
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
2009 Nov 13
1
[LLVMdev] Proposal: intp type
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
2009 Nov 13
7
[LLVMdev] Proposal: intp type
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
2009 Nov 13
0
[LLVMdev] Proposal: intp type
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
2009 Nov 13
0
[LLVMdev] Proposal: intp type
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. >>
2013 Nov 15
2
[LLVMdev] Modular arithmetic processors
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
2013 Nov 15
0
[LLVMdev] Modular arithmetic processors
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