similar to: [LLVMdev] What am I doing wrong here...

On 12/07/16 21:54, Michael S. Tsirkin wrote: > On Thu, Dec 08, 2016 at 05:21:47AM +0000, Bart Van Assche wrote: >> Additionally, there are notable exceptions to the rule that most drivers >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it >> would remain possible to check such drivers with sparse without enabling >> endianness checks. Have you

On 12/07/16 21:54, Michael S. Tsirkin wrote: > On Thu, Dec 08, 2016 at 05:21:47AM +0000, Bart Van Assche wrote: >> Additionally, there are notable exceptions to the rule that most drivers >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it >> would remain possible to check such drivers with sparse without enabling >> endianness checks. Have you

On Thu, Dec 08, 2016 at 06:38:11AM +0000, Bart Van Assche wrote: > On 12/07/16 21:54, Michael S. Tsirkin wrote: > > On Thu, Dec 08, 2016 at 05:21:47AM +0000, Bart Van Assche wrote: > >> Additionally, there are notable exceptions to the rule that most drivers > >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it > >> would remain possible

Hi Mike/Bart, On 12/8/16, 8:17 AM, "virtualization-bounces at lists.linux-foundation.org on behalf of Michael S. Tsirkin" <virtualization-bounces at lists.linux-foundation.org on behalf of mst at redhat.com> wrote: >On Thu, Dec 08, 2016 at 06:38:11AM +0000, Bart Van Assche wrote: >> On 12/07/16 21:54, Michael S. Tsirkin wrote: >> > On Thu, Dec 08, 2016 at

Hi Mike/Bart, On 12/8/16, 8:17 AM, "virtualization-bounces at lists.linux-foundation.org on behalf of Michael S. Tsirkin" <virtualization-bounces at lists.linux-foundation.org on behalf of mst at redhat.com> wrote: >On Thu, Dec 08, 2016 at 06:38:11AM +0000, Bart Van Assche wrote: >> On 12/07/16 21:54, Michael S. Tsirkin wrote: >> > On Thu, Dec 08, 2016 at

> Date: Thu, 17 Apr 2008 13:54:12 -0400 > From: "Jonathan S. Shapiro" <shap at eros-os.com> > > > > > The GC infrastructure exposes this information in a framework suitable > > for emitting metadata tables from a compiler plugin, if your interest > > lies in that direction. > > That too, but my immediate interest was computing an upper bound

I realized that WinEH preparation can probably be a lot less invasive than it is currently. Initially, when I was thinking about recovering the address of an object in a parent stack frame, I thought about it in terms of "let's allocate something at a fixed offset from ebp to keep things simple". That line of thinking suggested that we needed this thing to be fundamentally different

On Wed, Mar 4, 2015 at 12:36 AM, John McCall <rjmccall at apple.com> wrote: > > On Mar 3, 2015, at 2:25 PM, Reid Kleckner <rnk at google.com> wrote: > > > > I realized that WinEH preparation can probably be a lot less invasive > than it is currently. > > > > Initially, when I was thinking about recovering the address of an object > in a parent stack

Hi Chen, > I have recently encountered a problem when creating LLVM IRs. I am wondering > if there is a standard or easy way to create a load from a certain register? > For example, CreateLoad(rbp, NAME). LLVM doesn't directly provide access to any machine registers. If you want %rbp because it's the frame pointer then for that one case there is actually an @llvm.frameaddress

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

Hi Craig, On 03.07.19 17:33, Craig Topper wrote: > Don't the CreateICmp calls return a Value* with an i1 type? But then > they are added to an i8 type? Not sure that works.  I had that initially: auto cf = IRB.CreateICmpULT(Incr, ConstantInt::get(Int8Ty, 1)); auto carry = IRB.CreateZExt(cf, Int8Ty); Incr = IRB.CreateAdd(Incr, carry); it makes no difference to the generated assembly

Hello, I have an optimisation issue in an llvm IR pass - the issue being that unnecessary instructions are generated in the final assembly (with -O3). I want to create the following assembly snippet: mov dl,BYTE PTR [rsi+rdi*1] add dl,0x1 adc dl,0x0 mov BYTE PTR [rsi+rdi*1],dl however what is created is (variant #1): mov dl,BYTE PTR [rsi+rdx*1] add dl,0x1 cmp

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 so? Depending on how much precision you need, you could use the llvm.frameaddress

Hi, I would like to prevent that two adjacent calls to external functions getting interleaved/separated by other neighboring code. This mixing seems to happen in the code generator. I can prevent it by putting the two calls into a separate BB, but then I can't use -simplifycfg, -jump-threading, ... as is. Here is an example: %160 = add i64 %158, %159 ; <i64>

Hi, I'd like to know if there's a portable way of modifying the FP register, in LLVM. Suppose foo() calls bar(); bar emits a result but remains active and needs to be able to produce more results - a bit like a coroutine. We want bar to restore FP to what it was inside foo before transferring control back to foo (bar's stack frame is not disposed of). We'd make sure that foo

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

Hi, To add to what Anton said, what if you're on a non-x86 target, or --no-frame-pointer is set? Also, I'm intrigued as to how you guarantee that in the intervening time between the coroutine/generator function bar() returning one result and the next invocation of bar(), foo() doesn't call another function and overwrite bar()'s stack frame? Cheers, James Molloy Graduate

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

Misha Brukman wrote: > >>1. Opcodes and intrinsics >> > That's not really correct. The intrinsics such as llvm.frameaddress and > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > the intrinsics is specifically machine-dependent, and LLVM (and its > opcodes) are machine-independent, so there is no valid interchange of > these intrinsics

I'm at the stage where I'd like to try implementing exception handling for my little language. First off, I had a lot of difficulty understanding the documentation on exception handling until I went and started looking at the source code for libstdc++, in particular the definitions of __cxa_eh_globals and the functions that use it. I did not realize, until reading that code, that the