search for: arplynn

...as such #define ASSERT_STM(cond,expr) On Tue, Jul 26, 2011 at 6:36 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > He wants to be able to resume execution from the debugger after > assertion failure. > > Reid > > On Tue, Jul 26, 2011 at 8:07 PM, Alistair Lynn <arplynn at gmail.com> wrote: > > Hi- > > > >> Yep, but tripping the debugger is highly non-portable. > > > > You're suggesting that inline asm is more portable than calling abort? > > > > Alistair > > > > ______________________________________...

Hi- > Yep, but tripping the debugger is highly non-portable. You're suggesting that inline asm is more portable than calling abort? Alistair

He wants to be able to resume execution from the debugger after assertion failure. Reid On Tue, Jul 26, 2011 at 8:07 PM, Alistair Lynn <arplynn at gmail.com> wrote: > Hi- > >> Yep, but tripping the debugger is highly non-portable. > > You're suggesting that inline asm is more portable than calling abort? > > Alistair > > _______________________________________________ > LLVM Developers mailing list &...

...gt; > > On Tue, Jul 26, 2011 at 6:36 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > >> He wants to be able to resume execution from the debugger after >> assertion failure. >> >> Reid >> >> On Tue, Jul 26, 2011 at 8:07 PM, Alistair Lynn <arplynn at gmail.com> wrote: >> > Hi- >> > >> >> Yep, but tripping the debugger is highly non-portable. >> > >> > You're suggesting that inline asm is more portable than calling abort? >> > >> > Alistair >> > >> > __...

..., 2011 at 6:36 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: >> >>> He wants to be able to resume execution from the debugger after >>> assertion failure. >>> >>> Reid >>> >>> On Tue, Jul 26, 2011 at 8:07 PM, Alistair Lynn <arplynn at gmail.com> >>> wrote: >>> > Hi- >>> > >>> >> Yep, but tripping the debugger is highly non-portable. >>> > >>> > You're suggesting that inline asm is more portable than calling abort? >>> > >>> &gt...

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 >=

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

...oop, it can still be optimized. What I want to know is: is there any optimization supposed to optimize this code, but for some reason it thinks it is not possible, or there is no optimization for that situation at all? Thanks for the help guys On Tue, Jul 26, 2011 at 9:55 AM, Alistair Lynn <arplynn at gmail.com> wrote: > Hi- > > > I haven't seen a machine in which OR is faster than ADD nor more > energy-efficient. They're all done by the same ALU circuitry which delays > the pipeline by its worstcase path timing. So, for modern processor hardware > purposes, O...

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

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 haven't seen a machine in which OR is faster than ADD nor more energy-efficient. They're all done by the same ALU circuitry which delays the pipeline by its worstcase path timing. So, for modern processor hardware purposes, OR is exactly equal ADD. Transforming ADD to OR isn't strenght reduction at all. Maybe this is benefical only if you have a backend generating circuitry

..., 2011 at 6:36 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: >> >>> He wants to be able to resume execution from the debugger after >>> assertion failure. >>> >>> Reid >>> >>> On Tue, Jul 26, 2011 at 8:07 PM, Alistair Lynn <arplynn at gmail.com> >>> wrote: >>> > Hi- >>> > >>> >> Yep, but tripping the debugger is highly non-portable. >>> > >>> > You're suggesting that inline asm is more portable than calling abort? >>> > >>> &gt...

Yeah I had a think about it, and I think intrinsics are the wrong way to do it. So I'd say you are likely right. Bill. On 13 June 2010 04:33, Alistair Lynn <arplynn at gmail.com> wrote: > Hi Bill- > > I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the overflow intrinsics entirely. > > Alistair > > On 13 Jun 2010...

Hi Bill- I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the overflow intrinsics entirely. Alistair On 13 Jun 2010, at 02:27, Bill Hart wrote: > I was able to get the loop to increment from -999 to 0 using IR > directly. That got rid of the cmpq. > > The

Hi Steven- Nice, but will this not break Windows? From an initial glance over your patch, it seems to assume the existence of mmap() in some form or other. Alistair On 8 Aug 2010, at 03:05, Steven Noonan wrote: > Hi folks, > > I've been doing work on memory reduction in Unladen Swallow, and > during testing, LiveRanges seemed to be consuming one of the largest > chunks of

I was able to get the loop to increment from -999 to 0 using IR directly. That got rid of the cmpq. The carry i was after was able to be obtained using the intrinsic @llvm.uadd.with.overflow.i64, however there is no way to add with carry and have it realise that the resulting *carry out* cannot exceed 1. It actually writes the carry to a byte, and then uses logical operations on it, which slows

Hi folks, I've been doing work on memory reduction in Unladen Swallow, and during testing, LiveRanges seemed to be consuming one of the largest chunks of memory. I wrote a replacement allocator for use by BumpPtrAllocator which uses mmap()/munmap() in place of malloc()/free(). It has worked flawlessly in testing, and reduces memory usage quite nicely in Unladen Swallow. The code is available

Hello- Over the past couple of days I've been writing some very basic optimisations in -instcombine for the arithmetic with overflow intrinsics. As Duncan Sands pointed out on IRC however, this is duplicated effort when one can get equivalent results using weird sizes of ints in the IR. At present (at least, on x86/x86-64), the overflow intrinsics generate better code. So what

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 David- On 26 Apr 2010, at 21:05, David Greene wrote: > What's a "trap" and "trap value?" Is it some C++0X or Java thing? > It needs to be defined. See LangRef.html Alistair