similar to: [LLVMdev] Overflow intrinsics

Hi Russell- The PIC16 is an 8-bit target, and the msp430 is a 16-bit target. The rules about the largest supported integer no longer apply as much- for most operations, codegen can now handle arbitrary precision (exceptions: mul, udiv, urem, sdiv, srem). For those five, library calls should be emitted for big integers - best way to check if they're supported is to just try them :) Alastair

Hi Andrii-- They're not equivalent as far as LLVM is concerned - the parameter type is { { i32 }. { i64 } }* whereas the function is being given a { i32, i64 }*. Probably the easiest way to work around this is a simple bitcast. Alastair On 7 Sep 2009, at 00:32, Andrii Vasyliev wrote: > Hi! > > I have this error while building my code: > Assertion failed: ((i >=

Alastair Lynn wrote: > > From what I understand, the unwind instruction is implemented only > for the interpreter: there is a -lowerunwind pass for compiling to > other systems which will either lower unwind and invoke to setjmp/ > longjmp (slow) or turn invokes into calls and unwinds into abort()s. > Ah cheers, Alastair. That could be very useful (at least for me

Does LLVM support any target platforms on which the natural integer size/pointer size is smaller than 32 bits? For example, I noticed mention of PIC16, is that such a platform? If so, does the usual rule about the largest supported integer being the size of two pointers still apply? So that on that platform you can't use 64-bit integers, but you can use 32-bit integers?

Hi! I have this error while building my code: Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!") Actually I'm trying to load functions from .bc file and use them in the code that I'm building with IRBuilder. I found that function parameter type is %struct.reValue* and

Hi Dustin- You'll probably need to use insertvalue to construct your return value. Alastair On 7 Jan 2010, at 21:56, Dustin Laurence wrote: > define %Token @foo() > { > ... > > ret %Token {%c_int %token, %i8* %value} > }

Hi Robert- I notice that llvm-lua requires LLVM 2.4 rather than anything recent - are there any plans to upgrade? Alastair On 8 Jun 2009, at 14:34, Robert G. Jakabosky wrote: > > Have you tried llvm-lua? It adds JIT & static compiling support to > the Lua VM > using LLVM as the backend. I just released version 1.0 about a week > ago. > > The project website is

On 01/07/2010 06:03 PM, Alastair Lynn wrote: > > You'll probably need to use insertvalue to construct your return value. Ah ha! The fact is I didn't really understand the significance of this part when I read it, and so didn't remember it when I needed it. OK, so I have tested it and I can now build up a struct like this %s1 = insertvalue {i32, i32} {i32 0, i32 0}, i32

On 20/05/2010, at 8:16 AM, Chris Lattner wrote: > > On May 19, 2010, at 3:13 PM, o.j.sivart at gmail.com wrote: > >>> >>> Intrinsics should be optimized as well as instructions. In this specific case, these intrinsics should be marked readnone, which means that load/store optimization will ignore them. Dead code elimination will delete the intrinsic if it is dead

Do we have a .ll test cases for arithmetic overflow intrinsics that lli can execute and report any overflow occured? - sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110505/3a62c745/attachment.html>

On Tue, Apr 11, 2017 at 1:32 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Tue, Apr 11, 2017 at 1:11 PM, Alastair Bridgewater > <alastair.bridgewater at gmail.com> wrote: > > + /* HDMI 3D support */ > > + if ((disp->disp.oclass >= NV50_DISP) > > You probably meant G82_DISP. Although I don't know if there were any > G80's

I understand that overflow behaviours can be different on different hardware. But can we write .ll implementation of these overflow intrinsics, e.g. assuming 0..255 as value range for unsigned i8 ? - sanjiv On Thu, May 5, 2011 at 11:18 AM, Sanjiv <llvmdev at gmail.com> wrote: > Do we have a .ll test cases for arithmetic overflow intrinsics that lli can > execute and report any

Hello all, Having a problem with the Rspec textmate bundle and having quizzed the guys in #textmate to no success about the errors, I''ve been suggested to try you guys! When I run the "Run Behaviour Description" command, I get the following errors: /Users/alastair/Library/Application Support/TextMate/Bundles/ RSpec.tmbundle/Support/lib/spec/../spec/mate/runner.rb:34:in

From what I understand, the unwind instruction is implemented only for the interpreter: there is a -lowerunwind pass for compiling to other systems which will either lower unwind and invoke to setjmp/ longjmp (slow) or turn invokes into calls and unwinds into abort()s. On 26 Dec 2008, at 15:19, Matt Giuca wrote: > > > Jon Harrop wrote: >> >> Is it? I was just reading

Hi all, What would be the best/easiest way of installing rspec as a system wide generator so I''m not having to download it or ./script/plugin install it every time? Thanks, Alastair ----- Alastair Moore Freelance web design, development and consultancy t. 07983 983945 e. alastair at kozmo.co.uk w. http://www.kozmo.co.uk skype. alastair_kozmo

I recently upgraded both of my samba servers (mirrors of each other) to 3.0.4, my log files now fill with the following messages (hundred lines per day): Jun 24 13:55:33 Clyde smbd[8597]: [2004/06/24 13:55:33, 0] lib/util_str.c:safe_strcpy_fn(602) Jun 24 13:55:33 Clyde smbd[8597]: ERROR: string overflow by 1 (9 - 8) in safe_strcpy [LIBRA~V$.DOC] Jun 24 14:20:34 Clyde smbd[8597]: [2004/06/24

I've run into cases where, because not all of LLVM's optimizations understand the semantics of the `llvm.$op.with.overflow` intrinsics, canonicalizing compares to `llvm.$op.with.overflow` ends up preventing optimization. For instance, running the following snippet through `opt -indvars` optimizes `%to.optimize` to `true`, but running it through `opt -instcombine -indvars` does not. ```

> If we don't care about trying to optimize out overflow checks in > InstCombine, I'd go with moving the complexity to CGP. I think instcombine should optimize out overflow checks (as it does today) without introducing _with_overflow calls. Are there reasons why such an approach would not work? > However, I think > InstCombine is doing the right thing here by forming these.

Enable stereoscopic output for HDMI and DisplayPort connectors on NV50+ (G80+) hardware. We do not enable stereoscopy on older hardware in case there is some older board that still has HDMI output but for which we have no logic for setting the Vendor InfoFrame. With this, I get an obvious 3D output when using the "testdisplay" program from intel-gpu-tools with the "-3"

Jon Harrop wrote: > > Is it? I was just reading the documentation about LLVM's exception > handling > and it sounded ideal for my needs. How much of it does not work as the > docs > imply? > Jon, I ran into this issue in September and re-ignited this discussion in another thread, here: http://www.nabble.com/Unwinds-Gone-Wild-td18747589.html