Re: [lldb-dev] [3.8 Release] Release status
- Original Message - > From: "Renato Golin" > To: "Hans Wennborg" > Cc: "llvm-dev" , "cfe-dev" , > "LLDB Dev" , > "openmp-dev (openmp-...@lists.llvm.org)" , > release-test...@lists.llvm.org, "Cong Hou" > , "Davide Italiano" , "Quentin > Colombet" , "Hal Finkel" > , "Chandler Carruth" , "JF Bastien" > , "Nemanja Ivanovic" > , "Matthias Braun" > Sent: Friday, February 19, 2016 9:33:16 AM > Subject: Re: [lldb-dev] [3.8 Release] Release status > > On 19 February 2016 at 00:22, Hans Wennborg via lldb-dev > wrote: > > - PR26600: Loop vectorization creates an unsafe out-of-bounds load > > There's a patch out: http://reviews.llvm.org/D17332 > > But no comments yet.. Hal? > > This looks like a serious bug but Hal's idea is still unproven. I feel your statement misrepresents my review of the patch. What I said in the review was: [from review] How complicated would it be, instead of bailing out when we have a group without the last member, to peel off the last vector iteration instead (i.e. jump to the scalar tail loop one vector-loop iteration "early")? It seems like that would be a better solution (although, if you agree, but it seems too complicated to implement for the release branch, I'm fine with taking this (and pulling it into the release branch), and then implementing the better solution in trunk only). [end from review] What we have now is one easy fix, and I simply asked if we could get a much better easy fix in short order (i.e. for 3.8.0). Regardless, I feel I was quite clear in the review that this fix is otherwise fine, and we definitely need something for 3.8.0. It is a serious bug. Thanks again, Hal > I > think we should land the patch as it is, since it disables the bad > behaviour, and think about a fix later. Depending on how complex the > fix is, we might not even merge it into 3.8.x later on, but we need > the fix in 3.8.0. > > > > - ARM: fix VFP asm constraints: http://reviews.llvm.org/D17349 > > It's not a regression, but I'll take it if it lands real soon. > > No brainer. Accepted on trunk by compnerd, I'll merge into release_38 > shortly. > > cheers, > --renato > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
- Original Message - > From: "Hans Wennborg via cfe-dev" > To: "llvm-dev" , "cfe-dev" , > "LLDB Dev" , > "openmp-dev (openmp-...@lists.llvm.org)" > Cc: "r jordans" , "Paul Robinson" > > Sent: Monday, June 13, 2016 6:54:19 PM > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release > plan and call for testers) > > Breaking this out into a separate thread since it's kind of a > separate > issue, and to make sure people see it. > > If you have opinions on this, please chime in. I'd like to collect as > many arguments here as possible to make a good decision. The main > contestants are 4.0 and 3.10, and I've seen folks being equally > surprised by both. > > Brain-dump so far: > > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0 > comes after 3.9. > > - There are special bitcode stability rules [1] concerning major > version bumps. 2.0 and 3.0 had major IR changes, but since there > aren't any this time, we should go to 3.10. > > - The bitcode stability rules allow for breakage with major versions, > but it doesn't require it, so 4.0 is fine. > > - But maybe we want to save 4.0 for when we do have a significant IR > change? I think that this is the right approach, and we happen to have a natural forcing function here: opaque pointer types. I think we should increment the major version number when opaque pointer types are here, as it will be a major breaking change, and then we'll have a version 4.0. Until then, unless something else breaking comes up, 3.10 sounds fine to me. -Hal > > - We've never had an x.10 version before; maybe that would be > confusing? Perhaps it's simply time to move on (like Linux 2.6.39 -> > 3.0 and 3.19 -> 4.0). > > - Since we do time-based rather than feature-based releases, the > major > version number shouldn't mean anything special anyway (e.g. big IR > changes or not), so 4.0? > > - Everyone knows that after 9 comes 10, so 3.10 it is. The version is > a tuple after all. > > - Let's go for 4.0 now, and 5.0 after that. Then the "dot"-releases > in > between would correspond to minor version bumps, which would make > sense (and catch up with GCC!). > > - It's just a number, no big deal; flip a coin or something. > > What do you think? > > - Hans > > > [1]. > http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
- Original Message - > From: "Chris Lattner via Openmp-dev" > To: "Chris Lattner" > Cc: "llvm-dev" , "openmp-dev > (openmp-...@lists.llvm.org)" , "LLDB Dev" > , "Richard Smith" , > "cfe-dev" , "Paul Robinson" > > Sent: Saturday, June 18, 2016 11:20:19 PM > Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] What version comes > after 3.9? (Was: [3.9 Release] Release plan and call for testers) > > On Jun 18, 2016, at 9:16 PM, Chris Lattner via llvm-dev < > > llvm-...@lists.llvm.org > wrote: > > > On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev < > > cfe-...@lists.llvm.org > wrote: > > > > > I think that this is the right approach, and we happen to have > > > > a > > > > natural forcing function here: opaque pointer types. I think we > > > > should increment the major version number when opaque pointer > > > > types > > > > are here, as it will be a major breaking change, and then we'll > > > > have > > > > a version 4.0. Until then, unless something else breaking comes > > > > up, > > > > 3.10 sounds fine to me. > > > > > > > > > We're talking about version numbers for the entire LLVM project > > > here, > > > which encompasses a lot more than LLVM IR, and for many parts of > > > which LLVM IR is utterly irrelevant. I'm not convinced that tying > > > version numbers to backwards-incompatible changes to IR is > > > reasonable any more, and it doesn't seem hard to explicitly > > > document > > > the oldest version with which we are compatible (in fact, we need > > > to > > > do that regardless, whether we say it's "the same major version" > > > or > > > "everything since 3.0" or whatever else). > > > > > > Given that our releases are time-based rather than feature-based, > > > I > > > don't see a distinct major / minor version being anything other > > > than > > > arbitrary, so I'd suggest we take 4.0 as our next release, 4.1 as > > > the first patch release on that, 5.0 as the next release after > > > that, > > > and so on. > > > > > I completely agree with Richard here. “Breaking of IR > > compatibility” > > was an interesting metric for older and less mature versions of > > LLVM. We can solve the same sort of challenge (the desire to eject > > old autoupgrade code) by having a sliding window of versions > > supported (e.g. version 4.5 supports back to version 3.6). > > Let me clarify. What I’m trying to say is that: > a) LLVM has a time-based release cycle, not a schedule-based one. As > such, a simple and predictable version number makes sense. > b) The LLVM project as a whole is a lot bigger than LLVM IR, even > given its centrality to the project in some ways. > c) I think that it makes sense to keep adding 0.1 to each major > release going forward well into the future. > On the topic of the pointer changes proposed, I really don’t think > the community is served by waiting for that. The supposition seems > to be that we’d land it *without* upgrade support, but then bump the > major version number to indicate this. If that’s the proposal, I > think that doing such a thing would be disastrous for the LLVM > community as a whole To be clear, that's not at all what I was saying. The plan has always been to have upgrade support. My thought was that once the pointer changes land, it will mean major changes in how many frontends and IR transformations use the API. A lot of out-of-tree frontends and passes support multiple versions of LLVM, and use ifdefs to work around relevant API changes. For the most part, this works reasonably, and the changes necessary between versions are not often large (perhaps especially because we have time-based releases). I suspect, however, that the amount of code changes necessary to adapt for the pointer changes will be much larger, and so calling that a new major version seems fitting. -Hal > : we need to have at least some sliding window of support for older > formats. > -Chris > ___ > Openmp-dev mailing list > openmp-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
- Original Message - > From: "Chandler Carruth via Openmp-dev" > To: "Rafael Espíndola" , "Eric > Christopher" > Cc: "llvm-dev" , "Chris Lattner" > , "openmp-dev (openmp-...@lists.llvm.org)" > , "LLDB" , > "cfe-dev" , "David Blaikie" > , "Paul Robinson" > > Sent: Tuesday, June 28, 2016 2:55:21 PM > Subject: Re: [Openmp-dev] [cfe-dev] [llvm-dev] [lldb-dev] What > version comes after 3.9? (Was: [3.9 Release] Release plan and call > for testers) > ... > I actually don't care at all what the number is: 4 or 40 seem fine. > If 4 seems too confusing, and 40 seems too extreme, how about 10. > Seriously. It seems exactly as good as any other integer to start > counting rationally, and won't confuse people by looking like a 4.0 > release. I think that there are good marketing reasons to not be stuck at 3.x for a long time. People want to use actively-developed software that is neither too young (i.e. likely immature) nor too old. Thus, while always being on version 3.x is bad, being on version 50 or 100 also might send the wrong message. Given two releases per year, I think that starting at 40 is a bad idea, as we'll soon end up with numbers that look too large (in some subjective sense). Starting at 8 or 10 seems better. Also, many people are used to the odd/even numbering schemes used by many projects (i.e. odd is unstable and even is stable), and I've noticed that some people have an unconscious bias as a result, so we might stay away from odd numbers for that reason. -Hal > My 2 cents. > -Chandler > ___ > Openmp-dev mailing list > openmp-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] [Openmp-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
- Original Message - > From: "Hans Wennborg via llvm-dev" > To: "Richard Smith" > Cc: "llvm-dev" , "Chris Lattner" , > "openmp-dev > (openmp-...@lists.llvm.org)" , "LLDB" > , "cfe-dev" > , "David Blaikie" , "Paul > Robinson" > Sent: Tuesday, June 28, 2016 3:38:06 PM > Subject: Re: [llvm-dev] [lldb-dev] [cfe-dev] [Openmp-dev] What version comes > after 3.9? (Was: [3.9 Release] Release > plan and call for testers) > > On Tue, Jun 28, 2016 at 1:17 PM, Richard Smith via lldb-dev > wrote: > >> If 4 seems too confusing, and 40 seems too extreme, how about 10. > >> Seriously. It seems exactly as good as any other integer to start > >> counting > >> rationally, and won't confuse people by looking like a 4.0 > >> release. > > > > > > I think going to 10 or 40 is likely to be confusing, because > > there'll be two > > different ways to refer to the same version (people will say 3.10 > > when > > referring to version 10, or 38 when referring to version 3.8, > > respectively). > > This happened to Java in the version 1.6 / version 6 numbering > > transition. > > > > In order to preserve numbering continuity and minimize confusion, > > if we go > > from three-component versions (major.minor.patch) to two-component > > versions > > (major.patch), I would suggest we go from x.y.z to x+1.0. (This is > > also > > consistent with how GCC handled the transition.) > > I haven't followed how this worked out for GCC, but I worry that if > we > go from 3.9.0 to 4.0 with the intention of doing 5.0 next, users will > get confused when we ship 4.1 as a "dot" release instead of a major > release like we've used to. > > There's also the question of how to practically go from a 3-tuple to > a > 2-tuple. Should we drop it from the version string and dir names in > Clang? Do we drop __clang_patchlevel__ or just leave it at zero? I > see > GCC 5.4 is actually versioned as 5.4.0 so maybe that'd be the way to > do it? I think that the directory names should match the version string. Both are user-facing. For the macros, I'd rather set the minor version to 0, since "patch level" really is the correct descriptive name for the final digit in our stable releases. -Hal > > Cheers, > Hans > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
- Original Message - > From: "Aaron Ballman via cfe-dev" > To: "Chandler Carruth" > Cc: "llvm-dev" , "cfe-dev" , > "openmp-dev > (openmp-...@lists.llvm.org)" , "LLDB" > > Sent: Thursday, June 30, 2016 5:34:13 PM > Subject: Re: [cfe-dev] FYI: Landing the initial draft for an LLVM Code of > Conduct > > Thank you for your continuing efforts on the Code of Conduct! I > appreciate the efforts and strongly support this direction. > > ~Aaron +1 -Hal > > On Thu, Jun 30, 2016 at 2:55 PM, Chandler Carruth via cfe-dev > wrote: > > Hello folks, > > > > As mentioned some time ago[1], we’ve had a long (looong) series > > of > > discussions about establishing a code-of-conduct for the LLVM > > project as a > > whole over on the llvm-dev thread and the > > http://reviews.llvm.org/D13741 > > code review. > > > > The discussion has largely died down for some time, and towards the > > end > > there has been pretty wide support for the draft wording we have > > now. It > > isn’t perfect, and there are still some important questions around > > forming > > the advisory committee to handle reporting, but I think the wording > > is at a > > good point of compromise in a challenging area. > > > > Based on the support, I’m going to land the patch that adds the > > draft. I’m > > hoping this will immediately provide good advice and guidance, and > > I’m > > hoping to see motion on setting up a reasonable advisory committee > > and > > resolving any issues around reporting so we can make this an > > official part > > of the community. > > > > I sending this as a heads up so folks are aware, not to start a new > > discussion thread. There are existing discussion threads[2] on > > llvm-dev if > > folks want to join in active discussion or we can start fresh ones, > > but I > > would encourage people to carefully read the discussion that has > > already > > taken place to avoid revisiting areas that have already been > > heavily > > discussed. > > > > Also, many thanks to the folks who provided all their opinions on > > the > > mailing list threads and in person in long discussions about this > > topic. > > > > Thanks, > > -Chandler > > > > [1]: Prior announcements: > > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > > http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html > > http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html > > http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html > > > > [2]: Existing threads: > > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > > http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html > > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html > > > > ___ > > cfe-dev mailing list > > cfe-...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Build failure with llvm/IR/Attributes.gen?
Hi everyone, Starting a few days ago (between Sept 22nd and 23rd) my nightly builds including lldb starting failing: In file included from /path/to/llvm/include/llvm/IR/Argument.h:19:0, from /path/to/llvm/include/llvm/IR/Function.h:22, from /path/to/llvm/include/llvm/IR/Module.h:21, from /path/to/llvm/tools/lldb/include/lldb/Expression/IRExecutionUnit.h:22, from /path/to/llvm/tools/lldb/source/Expression/ExpressionVariable.cpp:12: /path/to/llvm/include/llvm/IR/Attributes.h:71:38: fatal error: llvm/IR/Attributes.gen: No such file or directory #include "llvm/IR/Attributes.gen" ^ compilation terminated. This might be simply the result of some unexpressed dependency in the cmake files (my build uses make -j72, so it tends to find these kinds of issues when they come up). Any ideas? Thanks again, Hal -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Build failure with llvm/IR/Attributes.gen?
- Original Message - > From: "Hal Finkel via lldb-dev" > To: lldb-dev@lists.llvm.org > Sent: Thursday, September 29, 2016 2:51:03 PM > Subject: [lldb-dev] Build failure with llvm/IR/Attributes.gen? > > Hi everyone, > > Starting a few days ago (between Sept 22nd and 23rd) my nightly > builds including lldb starting failing: > > In file included from /path/to/llvm/include/llvm/IR/Argument.h:19:0, > from /path/to/llvm/include/llvm/IR/Function.h:22, > from /path/to/llvm/include/llvm/IR/Module.h:21, > from > > /path/to/llvm/tools/lldb/include/lldb/Expression/IRExecutionUnit.h:22, > from > > /path/to/llvm/tools/lldb/source/Expression/ExpressionVariable.cpp:12: > /path/to/llvm/include/llvm/IR/Attributes.h:71:38: fatal error: > llvm/IR/Attributes.gen: No such file or directory > #include "llvm/IR/Attributes.gen" > ^ > compilation terminated. > > This might be simply the result of some unexpressed dependency in the > cmake files (my build uses make -j72, so it tends to find these > kinds of issues when they come up). Any ideas? [+Chris B.] Doing this seems to help: diff --git a/CMakeLists.txt b/CMakeLists.txt index 85d4b51..9615a3c 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -765,9 +765,9 @@ add_subdirectory(utils/TableGen) # an entire module might include header, which depends on intrinsics_gen. This # should be right after LLVMSupport and LLVMTableGen otherwise we introduce a # circular dependence. -if (LLVM_ENABLE_MODULES) +#if (LLVM_ENABLE_MODULES) list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen) -endif(LLVM_ENABLE_MODULES) +#endif(LLVM_ENABLE_MODULES) add_subdirectory(include/llvm) but that does not seem like a real solution. -Hal > > Thanks again, > Hal > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)
On 02/17/2017 12:16 AM, Mehdi Amini via lldb-dev wrote: Hello all, GSOC is around the corner, and the LLVM projects plans to participate again this year. For those who don’t know about GSOC, students are proposing a project that they will work on for 3 months. Amongst other, one goal for LLVM is to mentor students to become good developers and also contributors to the LLVM project (or user/advocate of LLVM for building other cool projects). A key part of the process is about how do we select the projects. The way we’ve done it last year, is that the volunteer mentors shared an email thread and ultimately each one individually ranked the projects. We kept the average grading for each project to ranked them overall. In order to make the process more transparent to student applicants, we want to formalize and announce the criteria for ranking and selection project. The purpose of this email is to gather community feedback about the criterion that mentors should apply when ranking projects, for example: - Should we favor a student which has past contributions to LLVM compared to a newcomer? Is it more important or as equally important as the quality of the proposal? I think that the quality of the proposal is the most important thing, however, we should be realistic about the amount of time it will take to bring a newcomer up to speed on our coding conventions, quality standards, review process, etc. and factor that into the decision-making process. - How should we rank (if any) “research or unbounded projects” vs “project with an immediate application”? Should we strive to keep a balance? Given the short time period involved, I favor projects of more immediate utility. This does not mean that there can't be interesting open questions, but in our judgment, these should be answerable in a matter of weeks (i.e. choosing between clear alternatives, understood tuning parameters, and the like). - What about “projects that touch LLVM/Clang/…” vs “projects that are building something on top of LLVM”? (For example this project was first proposed to be selected by LLVM before being rejected and finally picked by the Julia project directly: https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/ )? I think we need to base this on the overall benefit to the community. If working on a project built on top of LLVM will bring additional users, end up making LLVM more robust, etc. then there might be significant anticipated value. That having been said, in practice, justifying this value will probably be more difficult than for a project contributing to LLVM, Clang, etc. - Should we ask that the work is done upstream all along? In the past there have been project developed on GitHub outside the community that have never been merged. The LLVM developer policy has a full section insisting on incremental development ( http://llvm.org/docs/DeveloperPolicy.html#incremental-development ). I think we should insist on incremental upstream development. Thanks again, Hal Hopefully we should be able to provide a set of guidelines to student that would help them fill the best application, and avoid unfortunate surprise at the end of the process. We should have this discussion before receiving the projects proposals, which opens on 2/28. Best, -- Mehdi ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
