similar to: [LLVMdev] Proposal: extended MDString syntax

Hi Dan, I am not against adding multi-line support for Metadata. I am also okay with your syntax, and I am also okay with other solutions, such as escaping of \n’s or adopting c-style concatenations of strings on multiple lines. But I think that serialization of MachineFunction should not be done in metadata. I understand the problem that you pointer out that machine instructions refer to

On Wed, Jun 26, 2013 at 3:46 PM, Nadav Rotem <nrotem at apple.com> wrote: > But I think that serialization of MachineFunction should not be done in > metadata. I understand the problem that you pointer out that machine > instructions refer to LLVM-IR, but I don’t think that metadata is the right > container for them. Can you suggest an alternative solution? Can you describe

> > > I think that the two alternatives that are obvious are for the MF to contain > the IR, or for the IR to contain the MF. Alternatively, they can live in > parallel and the MF may reference the IR. I am not sure what is the right > approach here, but my gut feeling is that metadata is not necessarily the > right container for MF. Off the cuff I'd think that IR

On Jun 26, 2013, at 4:36 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Jun 26, 2013 at 4:30 PM, Eric Christopher <echristo at gmail.com> wrote: > Off the cuff I'd think that IR containing MF seems most reasonable and > the use of metadata to contain it seems to be good from two > perspectives I think: > > a) it already exists, > b)

One question I have about this, what is the use case that is being targeted here? Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bob Wilson Sent: Wednesday, June 26, 2013 10:43 PM To: Chandler Carruth Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Proposal: extended MDString syntax On Jun 26, 2013, at 4:36 PM, Chandler Carruth <chandlerc

On Wed, Jun 26, 2013 at 4:30 PM, Eric Christopher <echristo at gmail.com>wrote: > Off the cuff I'd think that IR containing MF seems most reasonable and > the use of metadata to contain it seems to be good from two > perspectives I think: > > a) it already exists, > b) oddly enough that we could get rid of the metadata and still have a > valid module/compilation

On Jun 26, 2013, at 4:18 PM, Eric Christopher <echristo at gmail.com> wrote: > (Note, this is the first I've heard of this plan and just figured it out myself) Yes, this is also the first time I heard about this and I haven’t had a chance to think about this problem too deeply. > > So inverting it so that MI contains LLVM IR instead of the other way > around? Then

On Jun 26, 2013, at 3:51 PM, Chandler Carruth <chandlerc at google.com> wrote: > Can you suggest an alternative solution? Can you describe why you don't think metadata is the right container? This alone isn't really helpful at moving us toward something that there has been widespread agreement LLVM needs. Hi Chandler, Sure, we can talk about serializing MF. But the discussion

On Thu, Jun 27, 2013 at 10:49 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Jun 27, 2013, at 10:12 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > > > > On Thu, Jun 27, 2013 at 9:50 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> > wrote: > > On Jun 26, 2013, at 4:18 PM, Eric Christopher <echristo at gmail.com> >

On Wed, Jun 26, 2013 at 3:59 PM, Nadav Rotem <nrotem at apple.com> wrote: > > On Jun 26, 2013, at 3:51 PM, Chandler Carruth <chandlerc at google.com> wrote: > > Can you suggest an alternative solution? Can you describe why you don't > think metadata is the right container? This alone isn't really helpful at > moving us toward something that there has been

-llvm-commits, +llvmdev > On Oct 2, 2014, at 2:57 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > Author: dexonsmith > Date: Thu Oct 2 16:56:57 2014 > New Revision: 218914 > > URL: http://llvm.org/viewvc/llvm-project?rev=218914&view=rev > Log: > DI: Fold constant arguments into a single MDString > > This patch addresses the first

Hi All, Type uniquing for C++ is in. Some data for Xalan with -flto -g: 9.9MB raw dwarf size, peak memory usage at 2.8GB The raw dwarf size was 58MB, memory usage was 7GB back in May, 2013. Other efforts at size reduction helped, and type uniquing improved on top of those. Data on building clang with "-flto -g" after type uniquing: 3.4GB MDNodes after parsing all bc files, 7GB

On Jun 27, 2013, at 10:12 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Jun 27, 2013 at 9:50 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > On Jun 26, 2013, at 4:18 PM, Eric Christopher <echristo at gmail.com> wrote: > > > So inverting it so that MI contains LLVM IR instead of the other way > > around? Then we'd need a

Dear all, I am looking to output assembly comments in my emitPrologue() function, just for my own readability. Searching for a way to do this found me this thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043722.html, which says that the best way to output comments from somewhere like emitPrologue() is to: 1. Create an MDString for the comment. 2. Attach it to an LLVM

On Thu, Jun 27, 2013 at 9:50 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > On Jun 26, 2013, at 4:18 PM, Eric Christopher <echristo at gmail.com> wrote: > > > So inverting it so that MI contains LLVM IR instead of the other way > > around? Then we'd need a serialization format for MI that happened to > > include a way of serializing LLVM IR within.

On Jun 26, 2013, at 4:18 PM, Eric Christopher <echristo at gmail.com> wrote: > So inverting it so that MI contains LLVM IR instead of the other way > around? Then we'd need a serialization format for MI that happened to > include a way of serializing LLVM IR within. From a quick "hey, this > seems reasonable" the idea of embedding the MI into the IR rather than

On Jun 26, 2013, at 4:18 PM, Eric Christopher <echristo at gmail.com> wrote: > On Wed, Jun 26, 2013 at 3:59 PM, Nadav Rotem <nrotem at apple.com> wrote: >> >> On Jun 26, 2013, at 3:51 PM, Chandler Carruth <chandlerc at google.com> wrote: >> >> Can you suggest an alternative solution? Can you describe why you don't >> think metadata is the

Not to distract, but the word, `procedurization' is not an English word. It's just leaping out at me when it is either procedure(s) (noun) or proceduralize (verb). Even processes would make sense. I couldn't help myself because the word was distracting. - Marc P.S. Not that my vote counts, but I'm more in the camp of Hal whose approach to tackling the parallelization

Hi Manman, Thanks for sending this summary and progress plans - it's great to see the impact your changes have had and ideas for future direction. Type uniquing for C++ is in. Some data for Xalan with -flto -g: > 9.9MB raw dwarf size, peak memory usage at 2.8GB > The raw dwarf size was 58MB, memory usage was 7GB back in May, 2013. > Other efforts at size reduction helped, and type

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM