similar to: [LLVMdev] [RFC] First-class debug info IR: MDLocation (redux)

Hi Paul, I'm not sure I see any reason to wait until after 3.6. More changes are incoming and it's better to get them over with sooner rather than spread out the pain. Thanks! -eric On Mon Jan 12 2015 at 9:52:48 PM Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > Would you mind terribly waiting a week, until after 3.6 is forked? > > We're barely

I suspect it would actually be *better* if I got all this in before the branch, since it'll make cherry-picking testcases easier. However, these patches themselves (and I suspect a few more prep commits) don't actually move `MDLocation` into place -- it's not until then that all the testcase updates have to happen. I'm not convinced that (monster) commit will land by tomorrow :(.

> On 2015 Jan 13, at 11:13, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > >> I suspect it would actually be *better* if I got all this in before >> the branch, since it'll make cherry-picking testcases easier. > > Excellent point, go for it. I missed the branch deadline, but I merged it in as of r226095. > --paulr > >> >>

I've attached a preliminary patch for `MDLocation` as a follow-up to the RFC [1] last week. It's not commit-ready -- in particular, it squashes a bunch of commits together and doesn't pass `make check` -- but I think it's close enough to indicate the direction and work toward consensus. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/077715.html IMO, the files to

> On 2015-Jan-14, at 11:26, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Jan 14, 2015, at 11:12 AM, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> >> On Wed, Jan 14, 2015 at 11:04 AM, Adrian Prantl <aprantl at apple.com> wrote: >> One small request: Omitting the column field from MDLocation if it is 0 is fine,

> On 2015-Jan-15, at 09:35, Hans Wennborg <hans at chromium.org> wrote: > > On Wed, Jan 14, 2015 at 8:26 PM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >>> On 2015 Jan 13, at 11:13, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: >>> >>>> I suspect it would actually be *better* if I got all this

On Wed, Jan 14, 2015 at 11:04 AM, Adrian Prantl <aprantl at apple.com> wrote: > One small request: Omitting the column field from MDLocation if it is 0 is > fine, because it won’t make it into the line table. Omitting the line if it > is 0 is not, because it gives the wrong impression that the line is being > ignored, which is not the case. Line 0 will be emitted in the line

I just finished the work for PR21433. I think it's relatively low risk, but it does change assembly output. Should I commit this before or after the (imminent) 3.6 branch? (I would have committed it tonight, but the buildbots are fairly red, and I prefer to break out-of-tree code in the morning anyway.) -------------- next part -------------- A non-text attachment was scrubbed... Name:

TL;DR: If you use metadata (especially if it's out-of-tree), check the numbered list of lost functionality below to see whether I'm trying to break your compiler permanently. In response to my recent commits (e.g., [1]) that changed API from `MDNode` to `Value`, Eric had a really interesting idea [2] -- split metadata entirely from the `Value` hierarchy, and drop general support for

Hi Folks, I ran into this assertion failure while compiling a function with a large number of arguments: https://llvm.org/bugs/show_bug.cgi?id=21609 I have coded up the fix as per David's suggestion (added a new header field for DIVariable to separate out ArgNo & LineNo). The proposed diff is attached to the bug. However, there are around 175 testcases across clang & llvm that need

On Tue, Jan 13, 2015 at 10:27 PM, Sameer Sahasrabuddhe < sameer.sahasrabuddhe at amd.com> wrote: > Ping! We need to close on whether everyone is convinced that symbolic > memory scopes have a significant advantage over opaque numbers. Either of > them will be examined by optimizations using a target-implemented API. I > personally don't think that readability in the LLVM

On Tue, Apr 28, 2015 at 7:14 PM, David Blaikie <dblaikie at gmail.com> wrote: > I believe duncan's fixed this recently in 235956 and 235955 - does ToT work > for you? It seems like r235955 might have fixed it. However I'm having build issues with ToT in my environment. Is this the right place to check ToT build status: http://lab.llvm.org:8011/one_line_per_build > > On

> On 2014-Oct-27, at 09:33, David Blaikie <dblaikie at gmail.com> wrote: > >> > Would it be possible to omit the names of unreferenced nested metadata? (if you have a bunch of member functions in a class, but don't need to refer to them elsewhere (eg: those member functions aren't defined in this translation unit)) - that'd help readability/writeability, but

On 15 January 2015 at 13:35, Renato Golin <renato.golin at linaro.org> wrote: > AArch64 tested and uploaded. ARMv7 in progress. Hi Hans, ARMv7 is giving me a bit of a headache... I've tried building on two different machines and I get the same error... Phase 2 completes successfully, but while building Phase 3, I get the error on *every* file: 1.

> On 2014-Oct-24, at 16:37, David Blaikie <dblaikie at gmail.com> wrote: > >> Notice that only the links to parents (i.e., `context:`) are explicit >> here -- backlinks are implied. For example, !7 and !8 point to !6, but >> not the reverse. > > This may be a problem - the difference between nodes in a structure/class_type's member list, and those that

On 1/9/2015 4:14 AM, Chandler Carruth wrote: > On Wed, Jan 7, 2015 at 8:03 PM, Sahasrabuddhe, Sameer > <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> > wrote: > > Here's what this looks like to me: > > 1. LLVM text format will use string symbols for memory scopes, > and not numbers. The set of strings is target

OK. I will do some experiments with (1) on Power PC. Will update this email chain about the results. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/f05c1bad/attachment.html>

On Tue, Mar 22, 2016 at 1:41 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Sorry I should have been more clear (writing to many email in parallel) > > You're right. I was adding a +1 to you here. > > Especially I wrote "unless there is an acknowledgement that typeless > pointers won't be there before a couple of years" with the PassManager in >

On Tue, Mar 22, 2016 at 7:33 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Mar 22, 2016, at 4:15 PM, Ehsan Amiri via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > James, > > I think (1) reduces the number of "do-not-see-through-bitcast" bugs that > we need to uncover and fix between now and the time that typeless pointer > is

But not what David was stating, unless I misread? I was specifically responding to David's wording: "If we're talking about making an optimization able to ignore the bitcast instructions - yes, that work is unnecessary & perhaps questionable given the typeless pointer work. Not outright off limits, but the same time might be better invested in moving typeless pointers