similar to: [LLVMdev] Metadata/Value split has landed

Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] Metadata/Value split has landed"

2014 Dec 10
2
[LLVMdev] Metadata/Value split has landed
> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >> The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the >> C++ side of it. This was a rocky day, but I suppose that's what I get >> for failing to stage the change in smaller pieces. >>
2014 Dec 10
3
[LLVMdev] Metadata/Value split has landed
> On 2014 Dec 10, at 14:08, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Dec 10, 2014 at 11:21:08AM -0800, Duncan P. N. Exon Smith wrote: >> >>> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: >>> >>> On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >>>> The `Metadata`/`Value`
2014 Dec 11
2
[LLVMdev] Metadata/Value split has landed
On Wed, Dec 10, 2014 at 05:27:45PM -0800, Duncan P. N. Exon Smith wrote: > +zalman at google.com > Hi Duncan, This patch plus another small change fixes the assertion failure for me. With the patch alone, the void* overload of addGarbageObject() was being used by MDNode::getTemporary(), so I had to cast the object as an MDNode*: diff --git a/lib/IR/Metadata.cpp b/lib/IR/Metadata.cpp
2014 Dec 11
2
[LLVMdev] Metadata/Value split has landed
I committed: r224058 = 966942da9e68b59c31ce770e7f94c55a63482c6b r224060 = da75f7277e3a129aed8ef8aa4e0d84de40b76fd4 r224061 = f88e4c8e9171045454b2c8e05054c2af8da3fe4f Let me know if somehow you're still hitting the problem. r224061 removes leak detection entirely from `MachineInstr`. There aren't any leaks to be had there, since they're allocated in a custom allocator. They're
2014 Dec 18
1
[LLVMdev] Metadata/Value split has landed
> On 2014-Dec-18, at 01:43, Keno Fischer <kfischer at college.harvard.edu> wrote: > > Hi Duncan, > > I'm in the following situation for which this change caused an assertion failure: > > Three modules, let's say A B C > Two function, F in A, G in B > > Now I CloneFunction F into B (call the new function F') and inline F' into G. > Now,
2013 Aug 20
2
[LLVMdev] Trying to run qt app compiled to bit code Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!")
Hi,  I am trying to run a simple qt 5 application compiled to bitcode on OS X. I am getting the following error. I have modified lli to load qt libraries. When I use with option mcjit, I get the following error lli -use-mcjit -debug-ir bitcodetestqtapp Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file
2013 Aug 20
0
[LLVMdev] Trying to run qt app compiled to bit code Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!")
Looks like a bug in the DebugIR pass. I imagine that without the -debug–ir flag, you will be able to get a little further. Nonetheless, can you send me the "bitcodetestqtapp" that you're running, or steps to reproduce? I'd love to take a look. Thanks, Dan From: Shailesh Kumar <shaileshkumar41 at yahoo.com<mailto:shaileshkumar41 at yahoo.com>> Reply-To: Shailesh
2012 Apr 22
2
[LLVMdev] Remove function from module
It is ModulePass with AnalysisUsage of CallGraph Yours sincerely, Kadysev Mikhail 22.04.2012, в 5:20, Nick Lewycky написал(а): > Михаил wrote: >> Thanks, but I replaceAllUsesWith() - works well, but I still get bug in >> eraseFromParent(): >> >> While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi >> An asserting value handle still pointed to this value! >>
2012 Apr 22
0
[LLVMdev] Remove function from module
Михаил wrote: > It is ModulePass with AnalysisUsage of CallGraph Ah, then you'll need to update the CallGraph first. Use "CG.removeFunctionFromModule(F);" before deleting it. Nick > Yours sincerely, > Kadysev Mikhail > > 22.04.2012, в 5:20, Nick Lewycky написал(а): > >> Михаил wrote: >>> Thanks, but I replaceAllUsesWith() - works well, but I still
2014 May 16
4
[LLVMdev] Writing an address space re-numbering pass?
Hi, I'm trying to figure how to write a Module pass that globally renumbers address space numbers e.g. >From -> To 0 -> 1 1 -> 3 2 -> 2 3 -> 4 4 -> 999 I see that the address space number is a property that belongs to Types[1] and that types are immutable, so I'm not sure how to correctly implement this. But if it is I'd greatly appreciate advise on how to do
2012 Aug 09
3
[LLVMdev] Type inconsistency in LLVM 3.1: CGDebugInfo.cpp
I'm probably missing something simple here but in: CGDebugInfo.h: std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; but then in CGDebugInfo.cpp: llvm::DIType TC = getTypeOrNull(Ty); void * v = Ty.getAsOpaquePtr(); std::pair<void *, llvm::WeakVH> tmp = std::make_pair(v, TC); if (TC.Verify() && TC.isForwardDecl())
2019 Mar 06
2
nvidia on 7.6
On 06/03/2019 21:53, Pete Geenhuizen wrote: > > > On 03/06/2019 04:21 PM, Phil Perry wrote: >> On 06/03/2019 19:30, Pete Geenhuizen wrote: >>> >>> That is all good and well, but my problem is that I now can't install >>> >>> vlc smplayer mplayer, or? ffmpeg-libs because they need >>> ocl-icd-2.2.12-1.el7.x86_64from epel.
2019 Mar 06
2
nvidia on 7.6
On 06/03/2019 19:30, Pete Geenhuizen wrote: > > > On 03/06/2019 09:59 AM, Fred Smith wrote: >> >>> I tried to install this and ran into a conflict >>> >>> --> Processing Conflict: >>> nvidia-x11-drv-340xx-340.107-2.el7_6.elrepo.x86_64 conflicts ocl-icd >>> --> Finished Dependency Resolution >>> Error: nvidia-x11-drv-340xx
2012 Aug 09
0
[LLVMdev] Type inconsistency in LLVM 3.1: CGDebugInfo.cpp
On 09.08.2012, at 19:43, "Gaster, Benedict" <Benedict.Gaster at amd.com> wrote: > I’m probably missing something simple here but in: > > CGDebugInfo.h: > > std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; > > but then in > > CGDebugInfo.cpp: > > llvm::DIType TC = getTypeOrNull(Ty); > > void * v =
2016 Jan 12
2
Assertion isUniqued() failure
I'm upgrading my application to use LLVM 3.7.1 instead of 3.5.1. On one of my regression tests I am getting an assertion: /home2/djones/llvm-3.7.1.src/lib/IR/Metadata.cpp:490: void llvm::MDNode::resolve(): Assertion `isUniqued() && "Expected this to be uniqued"' failed. This occurs when finalizing debug info prior to code generation: #4 0x00007ffff4520455 in
2012 Aug 09
1
[LLVMdev] Type inconsistency in LLVM 3.1: CGDebugInfo.cpp
Hi Ben, Thanks that helped a lot. The problem seems to be that with the move to C++11 we now have: void std::vector<_Ty>::push_back(std::pair<_Ty1,_Ty2> &&)' and there no conversion operator that can be applied to convert: 'std::pair<_Ty1,_Ty2>' to 'std::pair<_Ty3,_Ty4> && Where: [ _Ty1=void *,
2014 Oct 18
2
[LLVMdev] Dereferencing NULL pointer in IndVarSimplify.cpp?
Hi, Here is the code in IndVarSimplify.cpp. SmallVector<WeakVH, 16> DeadInsts; while (!DeadInsts.empty()) if (Instruction *Inst = dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val())) RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI); Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL pointer, the expression,
2016 Jul 15
2
clone function
On 14 July 2016 at 20:07, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jul 14, 2016, at 7:58 AM, Pierre Gagelin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > I am trying to use the CloneFunction from llvm/Transforms/Utils/Cloning.h > and I don't understand how the ValueToValueMapTy argument should be > initialized. For instance,
2009 Sep 08
2
[LLVMdev] LLVM 2.6 Branch Fails to Compile
Dear All, The LLVM 2.6 Release Branch doesn't compile for me on Mac OS X. The following patch seems to fix it (it adds a missing include file to get WeakVH defined). Has anyone else seen this breakage, or is it possible that I've got the wrong branch checked out? -- John T. Index: lib/Transforms/Scalar/DeadStoreElimination.cpp
2009 Sep 16
1
[LLVMdev] [proposal] Extensible IR metadata
On Tue, Sep 15, 2009 at 11:37 PM, Devang Patel <devang.patel at gmail.com> wrote: > On Fri, Sep 11, 2009 at 9:57 AM, Chris Lattner <clattner at apple.com> wrote: >> Devang's work on debug info prompted this, thoughts welcome: >> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt > > Here is partial initial implementation. > Thoughts ? setHasMetadata