similar to: [LLVMdev] LLVMContext

Hi devs: I'm trying to do something quite simple, but it seems I need to provide an LLVMContext& to do it. I'm not sure what the 'proper' LLVMContext would be in my situation. I'm writing an analysis that is a FunctionPass. At some point in the pass, I am given a Value * representing an N-bit integer. My goal is to contruct two ConstantInt instances, for comparison

Hi All, ORC's new concurrent compilation model generates some interesting lifetime and thread safety questions around LLVMContext: We need multiple LLVMContexts (one per module in the simplest case, but at least one per thread), and the lifetime of each context depends on the execution path of the JIT'd code. We would like to deallocate contexts once all modules associated with them have

Agreed, the existing ownership seems sub-optimal. I wouldn't say broken, but subtle at least - looks like you get the choice to either manage the ownership of the Module object yourself, or let the context handle it (eg: currently it'd be valid to just do "{ LLVMContext C; new Module(C); new Module(C); }" - Modules end up owned by the context and cleaned up there). Might be hard

A: When the types are created in different contexts. I've been running into a module validation error related to phi nodes produced by the GVN pass, where the types of the incoming values aren't the same instance of IntegerType i1. I'm not certain I've found the root cause of the problem yet, it's probably due to my handling of LLVMContext & Module life cycles, and this

I see what my problem is here.... I'll continue to move further. Seems like Richards fix is still okay. On 02/25/2014 02:42 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:41 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 02:38 PM, Eric Christopher wrote: >>> On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote:

I'm trying to just emit simple inline assembler (no constraints, inputs, etc.) Can anyone point me to an example of this..? This is corresponding to: __asm__ ("mfc1 $4,$f12"); This is what I tried but it's not correct. std::vector<llvm::Type *> AsmArgTypes; llvm::FunctionType *AsmFTy = llvm::FunctionType::get(Type::getVoidTy(FStub->getContext()),

On 03/19/2015 09:57 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:52 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > On 03/19/2015 09:38 AM, David Blaikie wrote: >> >> >> On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler >> <reed.kotler at imgtec.com <mailto:reed.kotler at

On 03/19/2015 09:38 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > On 03/19/2015 09:24 AM, David Blaikie wrote: >> >> >> On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler >> <reed.kotler at imgtec.com <mailto:reed.kotler at

On 03/19/2015 09:24 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > Well, you are an mclinker contributor > > > Me personally? Not that I know of. Sorry. I thought i had seen your name in an mclinker commit. > > and Google uses mclinker >

Well, you are an mclinker contributor and Google uses mclinker and now it's broken as the result of your change. I still don't see any justification to making a change in a public interface that is used by other non LLVM projects to fix some issue with clang warnings. People should be able to derive from those classes. I can't understand your reasoning as to why these classes must

If you can't make an executable test from C or C++ code then how do you know something works. Just by examination of the .s? On 09/30/2014 03:18 PM, Reed Kotler wrote: > If I wanted to call this function that they generated by hand, from C or > C+ code, how would that be done? > > if have seen cases where a real boolean gets generated but it was > something fairly involved.

On 02/24/2014 04:42 PM, Eric Christopher wrote: > On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at mips.com> wrote: >> I need to leave soon and will take a look in the morning. >> >> I did look at the autoconf input files configure.ac >> >> There is a disable-zlib but not a disable-valgrind, even though it seems >> like there used to be.

On 06/10/2014 05:51 PM, Pete Cooper wrote: > Hi Reed > > You can do this on the instruction itself by telling it 2 operands > must be the same register. For example, from X86: > > let Constraints = "$src1 = $dst" in > defm INSERTPS : SS41I_insertf32<0x21, "insertps">; > > Thanks, Hi Pete, Sorry. I should have been more specific. I'm

I used the A9 schedule as an example: http://llvm.org/svn/llvm-project/llvm/trunk/lib/Target/ARM/ARMScheduleA9.td The documentation could use more clarity, but this is how I was able to do it to always get two specific instructions to be scheduled together. ________________________________________ From: reed kotler [rkotler at mips.com] Sent: Tuesday, September 17, 2013 8:54 PM To: Micah Villmow

In the most basic case, I'd imagine something like this: auto C = std::make_shared<LLVMContext>(); struct ModuleAndSharedContextDeleter { std::shared_ptr<LLVMContext> C; operator()(Module *M) { delete M; } /* ctor to init C */}; std::unique_ptr<Module, ModuleAndSharedDeleter> M(new Module(C.get()), ModuleAndSharedContextDeleter(C)); (or invert this and traffic in structs

On 03/19/2015 08:55 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 4:30 AM, Reed Kotler <Reed.Kotler at imgtec.com > <mailto:Reed.Kotler at imgtec.com>> wrote: > > One could argue that mclinker is doing something good or not by > how it's using this class > but I don't see the need for parser<bool> to be final. That is a >

On 02/25/2014 02:38 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 09:30 AM, Richard Sandiford wrote: >>> reed kotler <rkotler at mips.com> writes: >>>> On 02/24/2014 04:42 PM, Eric Christopher wrote: >>>>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at

Jeremy Lakeman wrote: > A: When the types are created in different contexts. > > I've been running into a module validation error related to phi nodes > produced by the GVN pass, where the types of the incoming values aren't > the same instance of IntegerType i1. > > I'm not certain I've found the root cause of the problem yet, it's > probably due to my

I understand that but falling back makes the compilation slower. I'm wondering what could be done to remove this restriction about fast-isel not being able to handle non legal types. ________________________________________ From: Anton Korobeynikov [anton at korobeynikov.info] Sent: Sunday, August 31, 2014 12:55 AM To: Reed Kotler Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] lowering

Okay. Cool. So do you bootrstrap and verify as part of the usual testing? Do the nightly scripts do this? Reed On 06/28/2012 11:08 AM, Eric Christopher wrote: > On Jun 27, 2012, at 10:48 PM, Reed Kotler<rkotler at mips.com> wrote: > >> On 06/27/2012 05:00 PM, Eric Christopher wrote: >>> On Jun 19, 2012, at 5:24 PM, reed kotler<rkotler at mips.com> wrote: