similar to: [LLVMdev] Removing types from metadata

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

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. As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, so if I've missed some problem in the sea of buildbot errors, please flag me down. I'll follow up soon with

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

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

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

Hi, The LLVM language reference doesn't say that extern_weak is illegal for function definitions, but it seems this restriction is enforced in the code in some places: https://github.com/llvm-mirror/llvm/blob/master/lib/AsmParser/LLParser.cpp#L4591 https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#L327 However it is possible to create a bitcode file

On Wed, Dec 03, 2014 at 11:51:07AM -0800, Michael Zolotukhin wrote: > Hi Tom, > > I also have several patches that might be useful in 3.5.1. They all are stability fixes: > > r221009: Correctly update dom-tree after loop vectorizer. > r222451: Fix a trip-count overflow issue in LoopUnroll. > r223170 and r223171: PR21302.Vectorize only bottom-tested loops. > Hi Arnold,

The language reference states that local temporaries begin with index 0, but if I try that on my not-entirely-up-to-date v3.4 llc (it is like a week old), I get an error "instruction expected to be numbered '%1'". Also, quite a few examples in the LR uses %0 as a local identifier. Should I fix those or is it a problem in llc? -- Mikael -------------- next part --------------

On Sat, Nov 29, 2014 at 08:34:34PM +0100, Dimitry Andric wrote: > On 29 Nov 2014, at 02:48, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Nov 26, 2014 at 07:44:20PM +0100, Dimitry Andric wrote: > ... > >> I would like to propose the following additional patches for 3.5.1. These will already be part of the upcoming clang 3.5.0 import into the FreeBSD 11.0 base

Hi Duncan, On 5/6/12 6:12 PM, Duncan Sands wrote: > Hi Ralf, > >> Is there a clean way to attach metadata nodes to Arguments and/or >> BasicBlocks? > > not at the moment. Feel free to work on adding this functionality! I am looking into that now. I decided to temporarily go for the following syntax for BasicBlock metadata (subject to discussion): entry:

On Fri, Dec 19, 2014 at 12:56 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > However, I think this would set a bad precedent. There's nowhere else > (that I know of) where we accept two versions of assembly. The > LLParser is relatively easy to work with because it doesn't have that > kind of historical baggage. I can think of two precedents:

On Wednesday 10 February 2010 14:58:58 Dan Gohman wrote: > On Feb 10, 2010, at 12:42 PM, David Greene wrote: > > On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote: > >> I think that adding a bit to LoadSDNode and StoreSDNode would make > >> sense. > > > > Ok. The consequence is that a number of functions will have to change to > > propagate

On Feb 10, 2010, at 12:42 PM, David Greene wrote: > On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote: > >> I think that adding a bit to LoadSDNode and StoreSDNode would make sense. > > Ok. The consequence is that a number of functions will have to change to > propagate this bit, analogous to what happens with isVolatile. It's > essentially what we do

On May 7, 2012, at 7:21 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Duncan, > > On 5/6/12 6:12 PM, Duncan Sands wrote: >> Hi Ralf, >> >>> Is there a clean way to attach metadata nodes to Arguments and/or >>> BasicBlocks? >> >> not at the moment. Feel free to work on adding this functionality! > > I am looking into that

On Jan 16, 2010, at 11:15 AM, Talin wrote: > OK here's the patch for real this time :) > > On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test > "union.ll" does not work, so you probably don't want to check this > in as is. However, I'd be interested in any

We would need to access the LLVM debug metadata type information directly from LLVM types. It looks like the current clang and llvm-gcc don't support such an association, nor appears the LLVM itself do. (We are tracking TOT, but only once a month or so.) In terms of LLVM IR, apparantly this would simply mean optionally adding another metadata value to each type. For example, let us have a

If we were to implement the #unroll pragma, we would want to add metadata to loop headers. But, it's not a big deal since we can simply add this metadata to block terminators. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dan Gohman Sent: Tuesday, May 08, 2012 00:58 To: Ralf Karrenberg Cc: llvmdev at cs.uiuc.edu List

These warnings started appearing recently when building LLVM: llvm[2]: Compiling LLParser.cpp for Release build /Volumes/Data/Users/kremenek/llvm/lib/AsmParser/LLParser.cpp: In member function ‘bool llvm::LLParser::ParseBr(llvm::Instruction*&, llvm::LLParser::PerFunctionState&)’: /Volumes/Data/Users/kremenek/llvm/lib/AsmParser/LLParser.cpp:3195: warning: ‘Op1’ may be used uninitialized in

On Wed, Nov 26, 2014 at 07:44:20PM +0100, Dimitry Andric wrote: > On 26 Nov 2014, at 16:50, Tom Stellard <tom at stellard.net> wrote: > > > > On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote: > ... > > I will try to look at the patches today. I'm going to delay the release a week > > or so, because of all the merge requests I've received,

OK here's a new version of the patch - and the unions.ll test actually passes :) On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 16, 2010, at 11:15 AM, Talin wrote: > > OK here's the patch for real this time :) >> >> On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: >> Here's a work