similar to: [LLVMdev] bug in the JIT global variable emitter

On Oct 13, 2008, at 2:42 PMPDT, Nuno Lopes wrote: > Hi, > > Today I found a nice bug in the JIT global variable emitter. > The problem may lead to an assert() failure when doing the following: > 1) compile some function > 2) emit a global variable > 3) compile another function. an assert() may trigger in the JIT memory > manager > > This happens because the JIT

[resending since the previous copy was apparently dropped by the mailing list] >> Today I found a nice bug in the JIT global variable emitter. >> The problem may lead to an assert() failure when doing the following: >> 1) compile some function >> 2) emit a global variable >> 3) compile another function. an assert() may trigger in the JIT memory >> manager

>> Today I found a nice bug in the JIT global variable emitter. >> The problem may lead to an assert() failure when doing the following: >> 1) compile some function >> 2) emit a global variable >> 3) compile another function. an assert() may trigger in the JIT memory >> manager >> >> This happens because the JIT global variable emitter is using the

On Oct 14, 2008, at 2:32 PM, Nuno Lopes wrote: > [resending since the previous copy was apparently dropped by the > mailing > list] > >>> Today I found a nice bug in the JIT global variable emitter. >>> The problem may lead to an assert() failure when doing the >>> following: >>> 1) compile some function >>> 2) emit a global variable

On Oct 14, 2008, at 4:47 AMPDT, Nuno Lopes wrote: >>> Today I found a nice bug in the JIT global variable emitter. >>> The problem may lead to an assert() failure when doing the >>> following: >>> 1) compile some function >>> 2) emit a global variable >>> 3) compile another function. an assert() may trigger in the JIT >>> memory

>> Ok, thanks for the explanation. So my first patch doesn't work. >> Also, to be >> clear, this bug has nothing to do with overflowing the JIT memory >> buffer. >> I made another one that takes keeps the allocation of global >> variables in >> the JIT buffer, but it creates a new mem block if it doesn't exist >> (i.e. >> when dumping a

Thanks Nuno and Dale. Some comments: + /// allocateSpace - reserves space in the current block if any, or + /// allocate a new one of the given size + virtual void *allocateSpace(intptr_t Size, unsigned Alignment); + Please capitalize "reserves". + /// allocateSpace - general-purpose space allocator Better comments please. :-) Also please end the sentence with a period or Chris'

> + /// allocateSpace - reserves space in the current block if any, or > + /// allocate a new one of the given size + virtual void > *allocateSpace(intptr_t Size, unsigned Alignment); + > Please capitalize "reserves". ok. > + /// allocateSpace - general-purpose space allocator > Better comments please. :-) Also please end the sentence with a period > or Chris'

On Oct 16, 2008, at 11:29 AM, Nuno Lopes wrote: >> + /// allocateSpace - reserves space in the current block if any, or >> + /// allocate a new one of the given size + virtual void >> *allocateSpace(intptr_t Size, unsigned Alignment); + >> Please capitalize "reserves". > > ok. > > >> + /// allocateSpace - general-purpose space allocator >>

Not sure how off-topic this is, but should we consider/have we considered porting our InstCombines to Alive? The PLDI '15 paper even demos C++ extraction from Alive theorems. I think it'd be a small step from that to extracting tightly optimized VM code, not unlike what Tablegen emits. Everything would be so clean and readable and organized. And edge cases can still be handled manually,

Hi Sanjay, You used Alive correctly, of course :) At this moment we cannot give you the best precondition. It’s on the todo list, but it’s not even started yet. It’s a much harder problem to solve. We do have a mode to compute the best set of nsw/nuw/exact attributes in the transformed expression, but it’s not enabled on the web interface yet (InstCombine was missing quite a few cases last

Hi, As a follow up of this thread I've made a patch that implements a simple approach to propagate the function return values as described previously. It can transform e.g. the following program: define i32 @f(...) nounwind { (...) %cond = select i1 %tobool, i32 2, i32 3 ; <i32> [#uses=1] ret i32 %cond } define i32 @g(...) nounwind { entry: %call = call i32 (...)* @f() ;

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de

Hi, This is a follow up on a discussion around shufflevector with undef mask in https://reviews.llvm.org/D70641 and https://bugs.llvm.org/show_bug.cgi?id=43958. The current semantics of shufflevector in http://llvm.org/docs/LangRef.html#shufflevector-instruction states: "If the shuffle mask is undef, the result vector is undef. If any element of the mask operand is undef, that element

> Currently, the MachO and ELF Writers and MachineCodeEmitters are > hard-coded into LLVMTargetMachine and llc. I am also interested in working on this area and interested in writting a COFF file backend. > In other words, the 'object file generation' capabilities of the > Common Code Generator are not generic. I was looking at making a parallel class to MachineCodeEmitter,

On Sun, Feb 8, 2015 at 10:02 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > When you say, "we'd like to", I'm assuming your justification for this is > so that we can model poison using these undef semantics. Is that correct? > Yes, but I also think 'icmp sgt i32 undef, %a -> i1 undef' is a pretty reasonable transform by itself. Well-defined programs

I think calling the attribute "used" is confusing. I'd suggest the following: "not_poison": If an argument is marked not_poison, and the argument is poison at runtime, the call is instant UB. Whether an argument is poison is checked after the rules for other attributes like "nonnull" and "align" are applied. This makes it clear that the IR semantics

On Tue, Sep 16, 2008 at 1:59 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > This kind of transformation isn't currently done by LLVM (note that here > this pass is only removing case statements. other transformations are not of > my responsibility :). > The patch is available at > http://web.ist.utl.pt/nuno.lopes/llvm_function_ret_infer.txt > I would love to

I like the idea of a generic MachineCodeWriter, although I prefer the name 'ObjectFileWriter'... I think we need to take a hard look at which bits of the Writer/Emitter infrastructure are needed for what tasks (Object File Emittion, JIT, etc.) and make sure that our abstractions are flexible enough... As it stands at the moment, the Writer and Emitter classes could definately be merged

> So just to be clear (mainly so i can go back to letting y'all hash this out), in value numbering: > 1. I can value number all freeze operations on the same operand to the same value > *as long as* > 2. I replace all freeze values of the same operand with a single one. > > Or am i misunderstanding? > If i've got it right, the issue i see with #2 is whether i can