similar to: [LLVMdev] Checked arithmetic

On Mar 25, 2008, at 8:25 PM, Jonathan S. Shapiro wrote: > In looking at the LLVM reference manual, it is conspicuous that (a) > the > IR does not define condition codes, and (b) the IR does not define > opcodes that return condition results in addition to their > computational > results. We currently don't have this because noone has implemented it yet. It would be

On Tue, 2008-03-25 at 21:18 -0700, Chris Lattner wrote: > On Mar 25, 2008, at 8:25 PM, Jonathan S. Shapiro wrote: > > > In looking at the LLVM reference manual, it is conspicuous that (a) > > the > > IR does not define condition codes, and (b) the IR does not define > > opcodes that return condition results in addition to their > > computational > >

On Wed, 2008-03-26 at 11:02 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > > I want to background process this for a bit, but it would be helpful to > > discuss some approaches first. > > > > There would appear to be three approaches: > > > > 1. Introduce a CC register class into the IR. This seems to be a > >

On Wed, 2008-03-26 at 14:11 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > >> Why not define an "add with overflow" intrinsic that returns its value and > >> overflow bit as an i1? > > > > Chris: > > > > I understand several simple ways to implement add with carry. Your > > suggestion is one of them. What

Hi, > There would appear to be three approaches: > > 1. Introduce a CC register class into the IR. This seems to be a > fairly major overhaul. > > 2. Introduce a set of scalar and fp computation quasi-instructions > that accept the same arguments as their computational counterparts, > but produce *only* the condition code. For example: > >

On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > I want to background process this for a bit, but it would be helpful to > discuss some approaches first. > > There would appear to be three approaches: > > 1. Introduce a CC register class into the IR. This seems to be a > fairly major overhaul. > > 2. Introduce a set of scalar and fp computation quasi-instructions

On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: >> Why not define an "add with overflow" intrinsic that returns its value and >> overflow bit as an i1? > > Chris: > > I understand several simple ways to implement add with carry. Your > suggestion is one of them. What I'm trying to understand is how to > handle the conditional code issue generally.

John Regehr wrote: > Say on that note here's something that I want to see: a formal semantics > for LLVM in for example higher order logic. This would probably not be > that difficult. Except that some aspects of the host platform leak through to .bc files. This may or may not be a problem. > Once the semantics exists, you can either prove once and for all the that > each

In the course of applying Shapiro-Wilk to 100,000 samples of 60 items from 100,000 different distributions, I encountered a fatal error in apply(). This can be reconstructed as follows, using the attached data file distr.dat containing 2 lines of my original 100,000-line file: > version _ platform Windows arch x86 os Win32 system x86, Win32 status

Hi, I am trying to create a table with information from Shapiro Wilk's test of normality. However, it fails due to lack of sample size, it says, but the way I see it, this is not a problem. (See the table of sample sizes (almost) at the bottom). Applying a different function using a similar ftable call is not a problem (See the bottom table). This is R 2.1.0 on Linux (Gentoo). /Fredrik

On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > I guess my take is that when faced with an architectural question that > you eventually may have to address in full, quick fixes tend to accrete > that have to be undone when you get around to the general solution, and > these make implementing the general thing harder -- unless you have > thought it out in advance and the quick

On Wed, 2008-03-26 at 15:07 +0100, Duncan Sands wrote: > 4. Do arithmetic in a type with one more bit. For example, suppose you > want to know if an i32 add "x+y" will overflow. Extend x and y to 33 > bit integers, and do an i33 add. Inspect the upper bit to see if it > overflowed. Truncate to 32 bits to get the result. Probably codegen > can be taught to implement

On Thu, 2008-03-27 at 12:10 -0600, John Regehr wrote: > > Don't forget prover. :-) > > Say on that note here's something that I want to see: a formal semantics > for LLVM in for example higher order logic. This would probably not be > that difficult. > > The problem that this solves is that current verified compiler efforts > appear to be highly specific to

Hi Shap, > > 4. Do arithmetic in a type with one more bit. For example, suppose you > > want to know if an i32 add "x+y" will overflow. Extend x and y to 33 > > bit integers, and do an i33 add. Inspect the upper bit to see if it > > overflowed. Truncate to 32 bits to get the result. Probably codegen > > can be taught to implement this as a 32 bit add +

On Thu, 2008-03-27 at 09:51 -0600, John Regehr wrote: > Hey, you need to be careful with this reasoning or else you'll end up > implementing a whole new language, compiler, and OS. > > Oh wait nevermind :). Don't forget prover. :-) shap

On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: > > 1) Is there a way to declare an integer type in the IR that represents > > "an int the same size as a pointer" without specifying exactly the > > size > > of a pointer? > > No. Chris: There are other languages that specify a "word" type along these lines. Would it be worth considering

On Wed, 2008-03-26 at 23:48 +0100, Óscar Fuentes wrote: > "Jonathan S. Shapiro" <shap at eros-os.com> writes: > My front-end is very similar to yours in the feature of the multiple > instantiations on demand, etc. Oscar: after you have a chance to read my recent reply to Gordon, would you be kind enough to let me know whether you still believe the situations are similar.

I was re-reading the specification for extractelement and friends, and I notice that the index is restricted to i32. Since vectors might clearly have a larger number of elements on 64-bit platforms, I wonder if I am misunderstanding the intended use of these instructions. Is this indeed intended for vector and structure access in general, or is intended to support (only) more specialized SIMD

Owen: Can you clarify what kinds of dynamic linker issues you are seeing? I speculate that cross-library dependency resolution is high on the list, but what else? shap On Tue, 2008-05-13 at 21:44 -0500, Owen Anderson wrote: > On May 13, 2008, at 9:22 PM, Jonathan S. Shapiro wrote: > > Owen: > > > > This is not correct. As the API stabilizes, it will become > >

On Thu, 2008-04-17 at 10:49 -0700, Chris Lattner wrote: > On Thu, 17 Apr 2008, guan mailist wrote: > > Does anyone have good ideas to dynamically measure the stack size of a > > program by using LLVM. > > I am trying to add some new intrinsic functions after each "alloca" in > > bitcode. Is it a good way to do it? > > Any existing tools can help me to do