[lldb-dev] Jobs working on LLVM, Clang, and LLDB at Apple
The Apple compiler and debugger teams are seeking exceptional engineers (to work on LLVM, Clang and LLDB) who are passionate about improving software development tools. Detailed job descriptions follow. Please send all responses to llvm-job-ap...@group.apple.com, including the relevant job title and a CV. 1. Clang Frontend Engineer In this position, you will work on general frontend development in Clang, with a particular focus on engineering new language and compiler features. Experience with development of C++ frontends is desirable for this position, but all strong candidates with frontend experience are encouraged to apply. Key Qualifications * Strong C++ coding skills and a passion for writing clean, high performing code. * Knowledge of compiler frontends and related tools. * Familiarity with compiler optimizations, code generation, and overall design of compilers. * Expert knowledge of C and C++, with a detailed understanding of the C++ standard and Itanium C++ ABI. * (Optional, but a big plus) Experience with Objective C/C++. * (Optional, but a big plus) Knowledge of LLVM/Clang and open source development. * Excellent communication and interpersonal skills. 2. Compiler Engineer In this position, you will make sure we ship a high quality compiler to our users. This involves working on various components of the LLVM toolchain to support new features, fix bugs, and improve performance. Experience with compiler development is desirable for this position, but strong candidates with other kinds of system software experience are also encouraged to apply. Key Qualifications: * Strong C++ coding skills and a passion for writing great code. * Familiarity with compiler optimizations, code generation and overall design of compilers. * Experience debugging a complex software stack and/or system level issues. * Strong track record of building high quality software. * Strong communication and teamwork skills. 3. LLVM/Clang - QE The Apple compiler team is hiring experienced Quality Engineers to drive quality improvements in LLVM/Clang and associated low level tools. You will be working closely with the compiler team to develop comprehensive test coverage for the suite of compiler tools with a heavy focus on automation and integration testing. Key Qualifications * Experienced in C/C++ development * Knowledge of how compilers work * Experience with Python * Ability to investigate and debug difficult problems * Ability to work in cross functional teams * (Optional, but a big plus) Knowledge of LLVM/Clang and open source development. * Excellent communication and interpersonal skills. * Experience with Jenkins CI systems. 4. LLDB Engineer We are seeking an enthusiastic engineer to improve the development experience across all of our platforms. The LLDB team blends compiler technology and a deep understanding of the runtime representation of running processes to enable a rich debugging experience, as well as enabling the Swift REPL and Playgrounds. You will be working with a talented team to improve on established tools and find new ways to apply technology from LLVM, Clang, and Swift to exploring running code. Key Qualifications * Experienced in C/C++ development * Knowledge of how compilers work * Knowledge of modern operating systems * Ability to investigate and debug difficult problems * Ability to work in cross functional teams * (Optional) Familiar with Swift * (Optional) Experience with Python * (Optional, but a big plus) Knowledge of LLVM/Clang and open source development. * Excellent communication and interpersonal skills. 5. LLDB - QE We are looking for a experienced Quality Engineer who is passionate about improving software quality. You will work closely with the Debugger team to develop and improve our automated testing and design new integration tests for LLDB. You will need to be able to write and debug complex C/C++ code and delve deep into the complexities of debugging on all Apple devices. Key Qualifications * Experienced in C/C++ development * Knowledge of how compilers and debuggers work * Experience with Python * Ability to investigate and debug difficult problems * Ability to work in cross functional teams with varying schedules. * (Optional, but a big plus) Knowledge of LLVM/Clang and open source development. * Excellent communication and interpersonal skills. * Experience with CI systems. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [Openmp-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
> On 2016-Jun-28, at 13:17, Richard Smith via lldb-dev > wrote: > >>> I think I agree with Chris with 3.10 being the worst possible outcome. >> >> I'd be interested to understand why you or Chris thing 3.10 is the worst >> possible outcome. > > Personally: I think it would be a bad outcome, because if we go to 3.10, I do > not see when we would ever transition to 4.0. What change would be "large > enough" to classify as a new major version of all of LLVM? Given that we are > (presumably) going to have a "sliding window" support story for LLVM IR > changes, and even LLVM IR changes are irrelevant to a significant number of > LLVM subprojects (all of which share the same versioning scheme), it's not > clear to me what would justify this. > >> Chris has said it is because he thinks we'll never change the "3", but I >> don't understand why 3.10 is worse than 3.9 was in that respect. I happen to >> agree that we'll never change the "3", but I don't think this makes 3.10 a >> particularly bad choice. > > We've historically gone from x.9 to x+1.0, so this sets precedent, and we > seem to have the energy and motivation to discuss and possibly change our > version numbering scheme right now. For me, it's just a question of "if not > now, then when?". > >> I'm seeing pretty much zero support for continuing to have a major/minor >> split. As such, I pretty strongly suggest that as a community we move to a >> single integer that increments every (time based) release, and a .N that >> increments with every patch release off of that branch. GCC and numerous >> other projects work this way. >> >> 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 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 agree with Richard. While I don't have a strong opinion about 3.10.x vs. 4.x vs. 4.0.x (assuming we document our *actual* bitcode compatibility promise), I think both 10.x and 40.x are actively confusing. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] [Openmp-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
> On 2016-Jun-28, at 16:22, Hans Wennborg via cfe-dev > wrote: > > On Tue, Jun 28, 2016 at 2:37 PM, Chris Lattner via llvm-dev > wrote: >> On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev >> wrote: >>> >>> I think I agree with Chris with 3.10 being the worst possible outcome. >> >> >> I'd be interested to understand why you or Chris thing 3.10 is the worst >> possible outcome. >> >> Chris has said it is because he thinks we'll never change the "3”, >> >> >> Yes, that is one reason. >> >> but I don't understand why 3.10 is worse than 3.9 was in that respect. >> >> >> Because it breaks from the established pattern we have, and means that we >> never get to 4. >> >> I happen to agree that we'll never change the "3", but I don't think this >> makes 3.10 a particularly bad choice. >> >> >> If you agree that we’ll never change the 3, then you are staying that you >> believe it is ok for the version number to be meaningless. In that case, I >> can’t see why you’d object to a policy change. >> >> I believe that the version number is important. Which is why I care so much >> about it :-) >> >> I think/hope we can agree that “Bitcode compatibility” is an obsolete notion >> to encode into the version number - from a historical perspective, we only >> used that as rationale because it happened to align well for the 1.9 to 2.0 >> conversion and then used it as an excuse to shed some legacy in the 3.0 >> timeframe. >> >> Given that, and given that we have a time based release, we should either >> leave the versioning alone (3.9/4.0/4.1) or switch to a semantic versioning >> model 3.9/4.0/5.0/6.0 or 3.9/40/41/42). > > Since there seems to be some kind of rough consensus forming around > the idea of moving towards a model with x.y version numbers where we > increment x every six months and y for the "dot" releases in between, > let's take it to a code review: > > http://reviews.llvm.org/D21821 > > What angles am I missing? I'm sure this can break the world in > interesting ways. (It looks like Clang's cmake config is already set > up for this though, by checking CLANG_HAS_VERSION_PATCHLEVEL). For one thing, I can't find the patch on the mailing list ;). I'm guessing you missed adding llvm-commits as a subscriber? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
