similar to: [LLVMdev] (no subject)

On Fri, 21 Jan 2005 12:14:41 -0800, Reid Spencer <reid at x10sys.com> wrote: > > Sorry for the sad state of the cygwin build. I had hoped to have it > cleaned up by now but many other things have been taking my time. > Although the build has been succeeding in recent days, I'm not sure it > will buy you anything. NONE of the nightly tests pass on cygwin. <ulp!>

Marshall Spight wrote: >>FYI, work progresses on the Win32 native port which you might also find >>interesting. It might even get done before the cygwin stuff. Jeff Cohen >>is working on that. Perhaps he can indicate the status of that effort. >> >> > >I recall reading on the llvm archives somewhere that there are significant >performance issues with the

Hi, I'm looking into LLVM, and I must say it looks supremely cool. However, I'm having a hard time getting anywhere with it, since I don't have a linux machine here, and cygwin seems like a bit of a second-class citizen. The instructions to build the cygwin binaries are outdated, so I have to just make some guesses as to what the right thing to do is, and I'm apparently not

Several instruction set architectures include arithmetic operations that can trap on overflow, or support this feature with a separate trap-on-overflow-flag instruction (such as the x86 INTO instruction). I am adding a back-end to the Open Dylan compiler to generate LLVM IR. The original back-end, which generates x86 machine code, makes use of the INTO instruction, and the runtime turns the

>>>>> Martin Maechler >>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >>>>> Hugh Parsonage >>>>> on Tue, 8 Sep 2020 18:08:11 +1000 writes: >> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): >> $> R --vanilla >> x <- c(0L, -2e9:2e9) >> # > Segmentation

Hi, all. I have noticed that LLVM supports some Intrinsic Functions such as *"** llvm.sadd.with.overflow"* described in http://llvm.org/docs/LangRef.html#int_sadd_overflow. We can use these functions and needn't define the function bodies. For example, I can manually insert codes: * %res = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b) %sum = extractvalue

On Aug 9, 2010, at 10:44 AM, Peter S. Housel wrote: > Several instruction set architectures include arithmetic operations that can trap on overflow, or support this feature with a separate trap-on-overflow-flag instruction (such as the x86 INTO instruction). > > > I am adding a back-end to the Open Dylan compiler to generate LLVM IR. The original back-end, which generates x86

After chatting on IRC, Peter wants a very specific interrupt (int4 on x86). I suggested he add a new llvm.x86.int(i32) intrinsic, and use the existing branch on llvm.sadd.with.overflow intrinsic. The x86 backend can then turn jo+int4 into into when reasonable. -Chris On Aug 9, 2010, at 5:45 PM, Chris Lattner wrote: > > On Aug 9, 2010, at 10:44 AM, Peter S. Housel wrote: > >>

On Tue, 8 Sep 2020, Hugh Parsonage wrote: > Thanks Martin. On further testing, it seems that the segmentation > fault can only occur when the amount of obtainable memory is > sufficiently high. On my machine (admittedly with other processes > running): > > $ R --vanilla --max-mem-size=30G -e "x <- c(0L, -2e9:2e9)" > Segmentation fault > > $ R --vanilla

Hi guys, I just noticed that the LLVM has some node for signed/unsigned type( like udiv, sdiv), but why the ADD, SUB do not have the counter part sadd, uadd? best kevin

I'm interested in using @llvm.experimental.vector.reduce.smax/umax to implement runtime overflow checking for vectors. Here's an example checked addition, without vectors, and then I'll follow the example with what I would do for checked addition with vectors. Frontend code (zig): export fn entry() void { var a: i32 = 1; var b: i32 = 2; var x = a + b; } LLVM IR code:

Hi, What's the state of llvm on various platforms? I've tried working with it on windows/cygwin a few times, and been fairly frustrated. I made some abortive efforts on RedHat 9, which also didn't go so well, but I put much less time into them. Is there a plan or a timeline to end up with some low-intensity linux target? Sort of like: grab these three RPMs and go. Having to get my

>>>>> luke-tierney >>>>> on Tue, 8 Sep 2020 09:42:43 -0500 (CDT) writes: > On Tue, 8 Sep 2020, Martin Maechler wrote: >>>>>>> Martin Maechler >>>>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >> >>>>>>> Hugh Parsonage >>>>>>> on Tue, 8 Sep 2020

The IR update to allow vector types was here: https://reviews.llvm.org/D57090 ...we didn't update the docs at that time because it was not clear what the backend would do with that, but that might've changed with some of the more recent patches. On Sat, Feb 9, 2019 at 1:42 AM Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don't think I understand your

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

Hi Pete, > Or do you mean that the result of an add may not even be defined? In that case would reading it be considered UB in the case where the overflow bit was set? Yeah, this is the case I'm worried about: that for example sadd.with.overflow(INT_MAX, 1) might be designed to return { poison, true } instead of giving a useful result in the first element of the struct. John

Hi Marshall, LLVM *is* cool .. just not on cygwin! :) Sorry for the sad state of the cygwin build. I had hoped to have it cleaned up by now but many other things have been taking my time. Although the build has been succeeding in recent days, I'm not sure it will buy you anything. NONE of the nightly tests pass on cygwin. Until I can get some time to figure out why that is happening, I doubt

On Sat, Feb 9, 2019 at 6:25 PM Simon Pilgrim <llvm-dev at redking.me.uk> wrote: > The add/sub (+mul) overflow intrinsics are being updated to support > vectors to match the related add/sub saturation intrinsics. We haven't > updated the docs yet as legalization, vectorization and various minor bits > of plumbing still need to be finished before it can be officially supported

Hi, Everybody! I have a big table which named table_x, and all the elements in the table is very large! Now I want to do the summay on the talbe_x[,3]. Unfornately, I can't get the right result! And the R give the warning messages as follow: > sum(table_x[,3]) >[1] NA >Warning message: >interger overflow in sum(.);please use sum(as.numeric(.)) (the original upper message is

Chris Lattner wrote: > On May 5, 2009, at 8:09 PM, Talin wrote: > > >> I wanted to mention, by the way, that my need/desire for this hasn't >> gone away :) >> >> And my wish list still includes support for something like uintptr_t >> - a >> primitive integer type that is defined to always be the same size as a >> pointer, however large or