Page MenuHomePhabricator

tstellar (Tom Stellard)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 9 2017, 1:53 PM (206 w, 2 d)

Recent Activity

Yesterday

tstellar requested review of D95284: utils/release: Add script for building release documentation.
Fri, Jan 22, 8:54 PM · Restricted Project

Thu, Jan 21

tstellar added a comment to D94451: Proposal for adding Bazel build configuration in-tree with peripheral support.

Thanks for the updates. I think this proposal is ready to send to Chris (Step 4).

Thu, Jan 21, 7:08 PM
tstellar added a comment to D64830: [Xtensa 4/10] Add basic *td files with Xtensa architecture description..

@andreisfr I don't seen any major issues being raised with this backend. It would be great if there was a public official ISA document, but I don't think the lack of one is a blocker. Please make a last check of the reviews in phabricato to see if there are any outstanding issues. Then, I would recommend you take a look at the documentation @tonic posted. Specifically the 5 bullet points under the "The basic rules for a back-end to be upstreamed in experimental mode are:" header. If you think you meet those requirements, please re-send the RFC to the list, so we can discuss getting this added.

Thu, Jan 21, 6:53 PM · Restricted Project
tstellar added a comment to D95114: HowToReleaseLLVM: Add annual release schedule template.

I think "Week number" is too ambiguous to be a guide. If January starts on the last day of the week, does that still count as week#1? What day does the week start on, anyway--much of the world starts the week on Sunday, much of the world starts the week on Monday.
"Fourth Tuesday in January/July" is unambiguous and makes everything easier to plan. Using "Start + N weeks" for the rest of the target dates is fine.

Thu, Jan 21, 7:58 AM · Restricted Project

Wed, Jan 20

tstellar requested review of D95114: HowToReleaseLLVM: Add annual release schedule template.
Wed, Jan 20, 9:54 PM · Restricted Project
tstellar updated the diff for D94941: Add minor version to libclang.so and libclang-cpp.so SONAME.

Fix shared object symlinks.

Wed, Jan 20, 2:07 PM · Restricted Project
tstellar added inline comments to D94941: Add minor version to libclang.so and libclang-cpp.so SONAME.
Wed, Jan 20, 2:02 PM · Restricted Project
tstellar added inline comments to D94941: Add minor version to libclang.so and libclang-cpp.so SONAME.
Wed, Jan 20, 1:50 PM · Restricted Project
tstellar added a comment to D94941: Add minor version to libclang.so and libclang-cpp.so SONAME.

I might be wrong but if the ABI is incompatible, are we not supposed to update the SONAME itself?

Wed, Jan 20, 8:17 AM · Restricted Project

Tue, Jan 19

tstellar added reviewers for D94941: Add minor version to libclang.so and libclang-cpp.so SONAME: serge-sans-paille, cuviper.
Tue, Jan 19, 9:34 AM · Restricted Project
tstellar added inline comments to D94387: Add new LLVMComponents CMake module..
Tue, Jan 19, 7:28 AM · Restricted Project
tstellar added inline comments to D94387: Add new LLVMComponents CMake module..
Tue, Jan 19, 7:28 AM · Restricted Project

Mon, Jan 18

tstellar requested review of D94941: Add minor version to libclang.so and libclang-cpp.so SONAME.
Mon, Jan 18, 8:19 PM · Restricted Project

Fri, Jan 15

tstellar added a comment to D94451: Proposal for adding Bazel build configuration in-tree with peripheral support.

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

OK, I think it would be better if this pitch was about adding bazel specifically. I don't really see what having a generic "unsupported build system" pitch gains us, when the specific build systems will all still need to go through the RFC process.

So I must confess that I'm a bit frustrated by this comment, Tom. The reason I'm writing this as a pitch is because the RFC(s) I wrote were determined to be "controversial" even after we had a support policy that explicitly discussed build systems. As far as I can tell, none of the objections raised that made it controversial had to do with Bazel in particular or whether its addition could satisfy the requirements of the support policy, but rather had to do with adding unsupported build systems in general. That was surprising to me, since we'd just had a separate RFC for a support policy, which seems like it would have been the ideal time to raise such objections, but people made the reasonable argument that the writing of that policy was very new (although the policies it recorded were not) and the inclusion of build configurations might reasonably have been missed when people were reviewing it. The prevailing view on the thread seemed to be we should escalate the point about unsupported build systems to come to a decision. So in my mind, this pitch is to make explicit and allow further discussion on the inclusion of unsupported build systems in the support policy, whereas before it was just a sentence that mentioned them as an example. I'm sympathetic to that and don't want to be just slipping things through, but I'd also like to actually make progress here and I feel like we have entered exactly the situation you've described as being opposed to when requesting that we escalate to a pitch: that is a "battle of attrition". I think you've raised reasonable concerns about build system proliferation, and I think we should discuss them, but I'm not sure how me writing yet another iteration of this proposal actually helps us here.

I guess I'm fine making this proposal "Unsupported build systems are allowed and Bazel is, in particular", so we don't have to then do yet another RFC, but my plan was to just reopen the previous RFC and return to the issues of Bazel in particular (and even more specifically our implementation of the LLVM config for it, which I think there were some reasonable criticisms of). I'm worried that discussing the specific case means that if some poor soul wants to add, say, a Meson build or whatever they will have to relitigate these points that have already been decided.

Can you understand where I'm coming from here?

Yes, and I think there may be some misunderstanding here, because the main reason I suggested you include Bazel in this pitch was to try to save your time and energy.

When I first suggested doing a pitch, my assumption was that the RFC for Bazel would turn into a pitch for Bazel and that would be it, however if we proceed with this pitch as written, then we would have had 2 RFCs, 1 Pitch, and still no final decision about Bazel. This seems to me like much more work then what we need to do, not to mention the fact that it is very confusing, and I don't think it's really fair to expect people who object to the original RFC to keep objecting to all these new proposals.

Yeah I appreciate that :-) And I agree that splitting this into separate threads means that it's also harder for people to object and I that that's not fair either.

As I wrote before, I don't really see what a pitch like this would give us. I mean there are negatives to adding Bazel that would be negatives of adding any build systems, so if this pitch is approved, does that mean we aren't allowed to consider these 'generic' negatives when evaluating Bazel?

That is my understanding, yes. If we decide that in general, these negatives are OK as long as certain criteria are met, then I think the only burden on proposals should be "are these criteria met?". But then again, that was my understanding of the point of having a support policy, as well, but that doesn't seem to have solved anything.

I don't want this to be any more complicated than it has to be, and to me the ideal pitch would be: 1) Here are the criteria for adding an unsupported build system and 2) Here is why bazel meets this criteria. I believe you already have most of 1, so just add in 2, and then this can be the final discussion about Bazel.

The thing is that I feel like (1) was covered by the support policy and (2) was basically what I wrote in my last RFC (point by point explaining why I think this meets the description in the support policy). People's subsequent objections seemed almost exclusively about the idea of having unsupported build systems in-tree in general as opposed to anything about Bazel in particular (in addition you had various concerns about the particular implementation that I think are totally something we discuss, but didn't really seem controversial).

So I'm left confused about why we have a pitch at all. If the pitch is about Bazel, then what is controversial about Bazel, specifically? Besides that it's a build system and that for any give build system, many people hate it. Personally I hate CMake *and* Bazel, but I need to build my project so ¯\_(ツ)_/¯

Fri, Jan 15, 8:29 PM
tstellar updated subscribers of D92892: [clang] Change builtin object size to be compatible with GCC when sub-object is invalid.
Fri, Jan 15, 6:27 PM · Restricted Project
tstellar added a comment to D94451: Proposal for adding Bazel build configuration in-tree with peripheral support.

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

OK, I think it would be better if this pitch was about adding bazel specifically. I don't really see what having a generic "unsupported build system" pitch gains us, when the specific build systems will all still need to go through the RFC process.

So I must confess that I'm a bit frustrated by this comment, Tom. The reason I'm writing this as a pitch is because the RFC(s) I wrote were determined to be "controversial" even after we had a support policy that explicitly discussed build systems. As far as I can tell, none of the objections raised that made it controversial had to do with Bazel in particular or whether its addition could satisfy the requirements of the support policy, but rather had to do with adding unsupported build systems in general. That was surprising to me, since we'd just had a separate RFC for a support policy, which seems like it would have been the ideal time to raise such objections, but people made the reasonable argument that the writing of that policy was very new (although the policies it recorded were not) and the inclusion of build configurations might reasonably have been missed when people were reviewing it. The prevailing view on the thread seemed to be we should escalate the point about unsupported build systems to come to a decision. So in my mind, this pitch is to make explicit and allow further discussion on the inclusion of unsupported build systems in the support policy, whereas before it was just a sentence that mentioned them as an example. I'm sympathetic to that and don't want to be just slipping things through, but I'd also like to actually make progress here and I feel like we have entered exactly the situation you've described as being opposed to when requesting that we escalate to a pitch: that is a "battle of attrition". I think you've raised reasonable concerns about build system proliferation, and I think we should discuss them, but I'm not sure how me writing yet another iteration of this proposal actually helps us here.

I guess I'm fine making this proposal "Unsupported build systems are allowed and Bazel is, in particular", so we don't have to then do yet another RFC, but my plan was to just reopen the previous RFC and return to the issues of Bazel in particular (and even more specifically our implementation of the LLVM config for it, which I think there were some reasonable criticisms of). I'm worried that discussing the specific case means that if some poor soul wants to add, say, a Meson build or whatever they will have to relitigate these points that have already been decided.

Can you understand where I'm coming from here?

Fri, Jan 15, 6:19 PM
tstellar committed rW365470a4910d: Add 11.0.1 release and update release schedule (authored by tstellar).
Add 11.0.1 release and update release schedule
Fri, Jan 15, 12:00 AM

Thu, Jan 14

tstellar accepted D94157: [lit] Harmonize lit and llvm versionning.

This makes sense to me.

Thu, Jan 14, 11:09 PM · Restricted Project

Wed, Jan 13

tstellar added a comment to D94451: Proposal for adding Bazel build configuration in-tree with peripheral support.

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

Wed, Jan 13, 12:07 PM

Mon, Jan 11

tstellar committed rGeefd420e0037: [github] Move repo lockdown config into llvm-project repo (authored by tstellar).
[github] Move repo lockdown config into llvm-project repo
Mon, Jan 11, 4:25 PM
tstellar added a comment to D94451: Proposal for adding Bazel build configuration in-tree with peripheral support.

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

Mon, Jan 11, 3:50 PM
tstellar updated subscribers of D94387: Add new LLVMComponents CMake module..
Mon, Jan 11, 6:49 AM · Restricted Project

Mon, Jan 4

tstellar added inline comments to D93351: [llvm-shlib] Build backend libraries as loadable modules.
Mon, Jan 4, 11:10 AM · Restricted Project
tstellar updated subscribers of D93351: [llvm-shlib] Build backend libraries as loadable modules.
Mon, Jan 4, 8:40 AM · Restricted Project

Dec 21 2020

tstellar committed rGdbb01536f6f4: scan-view: Remove Reporter.py and associated AppleScript files (authored by tstellar).
scan-view: Remove Reporter.py and associated AppleScript files
Dec 21 2020, 7:25 PM
tstellar closed D93565: scan-view: Remove Reporter.py and associated AppleScript files.
Dec 21 2020, 7:24 PM · Restricted Project
tstellar committed rG7f40bb3b044f: HowToReleaseLLVM: Update document to match the current release process (authored by tstellar).
HowToReleaseLLVM: Update document to match the current release process
Dec 21 2020, 3:24 PM
tstellar closed D93493: HowToReleaseLLVM: Update document to match the current release process.
Dec 21 2020, 3:24 PM · Restricted Project
tstellar committed rG4ad0cfd4de41: llvm-profgen: Parse command line arguments after initializing targets (authored by tstellar).
llvm-profgen: Parse command line arguments after initializing targets
Dec 21 2020, 3:13 PM
tstellar closed D93348: llvm-profgen: Parse command line arguments after initializing targets.
Dec 21 2020, 3:13 PM · Restricted Project

Dec 18 2020

tstellar requested review of D93565: scan-view: Remove Reporter.py and associated AppleScript files.
Dec 18 2020, 3:23 PM · Restricted Project

Dec 17 2020

tstellar requested review of D93493: HowToReleaseLLVM: Update document to match the current release process.
Dec 17 2020, 2:35 PM · Restricted Project
tstellar committed rG3203143f1356: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int) (authored by tstellar).
CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int)
Dec 17 2020, 2:31 PM
tstellar closed D84405: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int).
Dec 17 2020, 2:31 PM · Restricted Project

Dec 15 2020

tstellar requested review of D93351: [llvm-shlib] Build backend libraries as loadable modules.
Dec 15 2020, 3:21 PM · Restricted Project
tstellar requested review of D93348: llvm-profgen: Parse command line arguments after initializing targets.
Dec 15 2020, 3:14 PM · Restricted Project

Dec 14 2020

tstellar added a comment to D92052: [MC][ELF] Accept abbreviated form with sh_flags and sh_entsize.

This is about assembling GCC's -S output with LLVM's integrated assembler, which isn't an area that I think people frequently use, so I'd also hear from @burnus why this is urgent.

GCC's AMD GCN (alias Radeon) target (most useful for offloading) uses LLVM's assembler as GNU Binutils does not support GCN (yet?).

Many Linux distributions build GCC with offloading support for nvptx and amd gcn (installable was optional add-on packages).

The issue was found as building GCC was breaking on Debian once LLVM 11.0.0 was imported into Debian unstable. (Happens during the build of newlib's libc for GCN; this uses -ffunction-section). First reported at https://gcc.gnu.org/PR97827

Dec 14 2020, 10:07 AM · Restricted Project
tstellar added a comment to D92052: [MC][ELF] Accept abbreviated form with sh_flags and sh_entsize.

@jhenderson What's your opinion on backporting this?

Dec 14 2020, 7:00 AM · Restricted Project

Dec 9 2020

tstellar added a comment to D91935: [MCJIT] Add cmake variables to customize ittapi git location and revision..

In my opinion , it would be better to to build against an installed version of the library, rather than fetching the git source. But I don't have any objections to this specific patch, because it is updating something that is already in tree.

Dec 9 2020, 7:20 AM · Restricted Project

Dec 4 2020

tstellar added a comment to D92686: [Support] Add workaround for a bug in fuse-overlayfs.

Looking for feedback on if we want this kind of workaround in tree.

Dec 4 2020, 1:34 PM · Restricted Project
tstellar requested review of D92686: [Support] Add workaround for a bug in fuse-overlayfs.
Dec 4 2020, 1:33 PM · Restricted Project
tstellar added a comment to D92521: [tsan] Fix build failure with _FORTIFY_SOURCE.

Can you add a test probably in sanitizer_common which reproduces the issue?

Dec 4 2020, 12:00 PM · Restricted Project

Dec 3 2020

tstellar added a comment to D92518: [msan] Use REAL macro when calling intercepted function.

This code needs to call the interceptor to unpoison the output buffer.

As an alternative, unpoison the buffer after the REAL call (just copy the chunk from the previous function).

What problem does this change solve?

Dec 3 2020, 5:17 PM · Restricted Project

Dec 2 2020

tstellar requested review of D92521: [tsan] Fix build failure with _FORTIFY_SOURCE.
Dec 2 2020, 4:01 PM · Restricted Project
tstellar requested review of D92519: [tsan] Use REAL macro when calling intercepted function.
Dec 2 2020, 3:56 PM · Restricted Project
tstellar requested review of D92518: [msan] Use REAL macro when calling intercepted function.
Dec 2 2020, 3:54 PM · Restricted Project
tstellar added a comment to D92445: [PowerPC] Enable OpenMP for powerpcle target. [5/5].

Could you add some more information to the commit message to better describe the powerpcle target. It's not clear from the target name exactly what it is for.

Dec 2 2020, 7:56 AM · Restricted Project, Restricted Project, Restricted Project

Nov 24 2020

tstellar added a comment to D91935: [MCJIT] Add cmake variables to customize ittapi git location and revision..

Thanks for the explanation. Doing a git clone as part of the build is usually discouraged, though I see Lang approved the original patch. Is this code disabled by default?

Nov 24 2020, 8:14 PM · Restricted Project
tstellar requested changes to D91935: [MCJIT] Add cmake variables to customize ittapi git location and revision..

Can you explain more about what llorg is and why this change is needed?

Nov 24 2020, 10:42 AM · Restricted Project

Nov 20 2020

tstellar committed rGda886bf471e7: GitHub Actions: Add job for automatically updating the main branch (authored by tstellar).
GitHub Actions: Add job for automatically updating the main branch
Nov 20 2020, 10:28 PM
tstellar closed D91554: GitHub Actions: Add job for automatically updating the main branch.
Nov 20 2020, 10:27 PM · Restricted Project

Nov 19 2020

tstellar updated subscribers of D91760: [Driver] Default Generic_GCC aarch64 to use -fasynchronous-unwind-tables.
Nov 19 2020, 1:48 PM · Restricted Project

Nov 17 2020

tstellar added a comment to D91598: Allow packager to provide a default configuration file for clang.

Can you give an example of how this would be used to select the gcc-toolchain?

Nov 17 2020, 8:06 AM
tstellar added a comment to D91598: Allow packager to provide a default configuration file for clang.

@sylvestre.ledru Can you drop the picture?

Nov 17 2020, 8:04 AM

Nov 16 2020

tstellar accepted D91494: Build reproducible tarballs for releases.

This is fine with me.

Nov 16 2020, 8:29 PM · Restricted Project
tstellar added a comment to D91554: GitHub Actions: Add job for automatically updating the main branch.

I'm not sure if I'm going to be able to restrict commits to the branch to only the GitHub Actions bot, so I may need to swap out github.token for a github secret that uses the llvmbot token. If necessary, I will make this change as a follow up commit after I've done some testing.

Nov 16 2020, 11:10 AM · Restricted Project
tstellar requested review of D91554: GitHub Actions: Add job for automatically updating the main branch.
Nov 16 2020, 11:07 AM · Restricted Project

Nov 13 2020

tstellar added a comment to D91468: [llvm] Add OpenACC as a dependency to llvm-config.

I know this fixes a bug, but I don't think this is quite correct. It's really only the test that depends on the library not the tool. You could add LLVMFrontendOpenACC as a dependency to the check target, but it's pretty uncommon for an LLVM library to not have any tests. I think it would be better to fix this by adding a test case for LLVMFrontendOpenACC.

Nov 13 2020, 4:53 PM · Restricted Project
tstellar added a comment to D90848: llvmbuildectomy - part 2.

There was an inconsistency in the LLVMBuild.txt for LLVM Frontend: OpenACC wasn't listed but it was part of the CMake infrastructure. A side effect of the llvmbuildectomy has been to remove that inconsistency and register OpenACC as a regular component.

Looking at the error log, there is a missing libLLVMFrontendOpenACC.a
But I cannot see any reference to FrontendOpenACC in the build log, just as if it wasn't build, which is odd.
I failed to reproduce your issue, but does that OpenACC stuff rings any bell? Can you force building that component and see what happens?

Forcing a build of OpenACC then re-running the test fixes my issue. Is there perhaps someway in cmake to indicate that this library should just automatically be built whenever I run ninja check-llvm?

My cmake invocation also if it helps is:

cmake -GNinja       -DCMAKE_BUILD_TYPE=Debug       -DCMAKE_C_COMPILER=/usr/local/google/home/leonardchan/fuchsia/prebuilt/third_party/clang/linux-x64/bin/clang       -DCMAKE_CXX_COMPILER=/usr/local/google/home/leonardchan/fuchsia/prebuilt/third_party/clang/linux-x64/bin/clang++         -DLLVM_ENABLE_LLD=ON       -DCMAKE_EXPORT_COMPILE_COMMANDS=ON       -DLLVM_ENABLE_PROJECTS="clang"   -DLLVM_ENABLE_LIBCXX=On /usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-5/llvm

followed by LIT_FILTER=booleans.test ninja check-llvm.

Nov 13 2020, 2:24 PM · Restricted Project

Nov 11 2020

tstellar added reviewers for D90457: [clang][driver] Set LTO mode based on input files: MaskRay, mtrofin.
Nov 11 2020, 7:12 PM · Restricted Project

Nov 9 2020

tstellar added a comment to D91107: [Clang][Driver] Added the support for setting GCC toolchain via environment variable.

This code could be improved, but I don't think adding a specific environment variable for this a good solution. You can use the existing CCC_OVERRIDE_OPTIONS to get the same effect. e.g. CCC_OVERRIDE_OPTIONS=^--gcc-toolchain=/path/to/gcc

Nov 9 2020, 4:23 PM · Restricted Project
tstellar updated subscribers of D91107: [Clang][Driver] Added the support for setting GCC toolchain via environment variable.
Nov 9 2020, 4:18 PM · Restricted Project

Nov 6 2020

tstellar added inline comments to D90946: [IR] [TableGen] Cleanup pass over the IR TableGen files.
Nov 6 2020, 7:39 AM · Restricted Project

Nov 2 2020

tstellar added a comment to D89142: llvmbuildectomy.

Since it's rewriting each LLVMBuild.txt, I wouldn't call it minimal. It may however, it reduce risks by keeping the solutions similar to each other, but also also reduces the benefit. That is, what is the advantage of replacing scripts written in Python by the same scripts rewritten in CMake? Practically, we still need Python for llvm-lit, extract_symbols.py, libc (gen_hdr.py), libcxxabi, compiler-rt (gen_dynamic_list.py), ...

I see the biggest disadvantage of LLVMBuild that one has to redundantly specify library dependencies that must be kept consistent and other subprojects (such as clang) don't even use. This approach doesn't fix that.

Current step also removes (and not replace) a few LLVMBuild.txt, whenever it was only used to describe tools dependencies. And it makes the scope of the change well defined and easier to tackle than a whole python package.

That bein g said, I agree it's only the first step toward removing the LLVMBuild.* files, and the redunduncy between these files and the regular CMakeFiles.txt. I just don't want to do all the changes at once, and this one is already a big change!

Nov 2 2020, 9:24 AM · Restricted Project
tstellar added a reviewer for D89142: llvmbuildectomy: smeenai.
Nov 2 2020, 9:20 AM · Restricted Project

Oct 30 2020

tstellar accepted D90136: [lit] Ship and bundle license for lit package.

LGTM.

Oct 30 2020, 6:54 AM · Restricted Project

Oct 26 2020

tstellar accepted D90100: Add release tarballs for libclc.

LGTM.

Oct 26 2020, 6:15 AM · Restricted Project

Oct 22 2020

tstellar requested review of D90007: [clang][Sema] Fix PR47676: Handle dependent AltiVec C-style cast.
Oct 22 2020, 9:27 PM · Restricted Project
tstellar committed rG6f798e460ca3: HowToReleaseLLVM: Clean up document and remove references to SVN (authored by tstellar).
HowToReleaseLLVM: Clean up document and remove references to SVN
Oct 22 2020, 11:35 AM
tstellar closed D80395: HowToReleaseLLVM: Clean up document and remove references to SVN.
Oct 22 2020, 11:35 AM · Restricted Project

Aug 17 2020

tstellar committed rGc37145cab121: libclc: Add Mesa/SPIR-V target (authored by airlied).
libclc: Add Mesa/SPIR-V target
Aug 17 2020, 2:02 PM
tstellar closed D77589: libclc: Add Mesa/SPIR-V target.
Aug 17 2020, 2:02 PM · Restricted Project
tstellar committed rG3d21fa56f5f5: libclc: Make all built-ins overloadable (authored by daniels).
libclc: Make all built-ins overloadable
Aug 17 2020, 1:56 PM
tstellar closed D82078: libclc: Make all built-ins overloadable.
Aug 17 2020, 1:56 PM · Restricted Project
tstellar committed rG3a7051d9c28e: libclc: Fix FP_ILOGBNAN definition (authored by bbrezillon).
libclc: Fix FP_ILOGBNAN definition
Aug 17 2020, 1:48 PM
tstellar closed D83473: libclc: Fix FP_ILOGBNAN definition.
Aug 17 2020, 1:47 PM · Restricted Project
tstellar added a comment to D84392: libclc: add printf support on amd target.

This is fine with me.

Aug 17 2020, 7:56 AM
tstellar added a comment to D85630: [cmake] Don't build with -O3 -fPIC on Solaris/sparcv9.
In D85630#2220694, @ro wrote:

Ping? It's been a week, the patch fixes ca. 250 testsuite failures and is this a candidate for LLVM 11.0.0 rc2.

Aug 17 2020, 7:56 AM · Restricted Project

Aug 12 2020

tstellar accepted D85844: [Driver] Change -fnostack-clash-protection to -fno-stack-clash-protection.

LGTM. Thanks.

Aug 12 2020, 9:33 AM · Restricted Project

Aug 11 2020

tstellar added a comment to D74051: Move update_cc_test_checks.py tests to clang.

Nevermind, I figured out good enough workaround.

Aug 11 2020, 4:27 PM · Restricted Project, Restricted Project
tstellar added a comment to D82847: [CMAKE] Fix 'clean' target not working.

Reverting this patch seems to fix the error for me. Are you still seeing this same error in trunk?

Aug 11 2020, 2:55 PM · Restricted Project
tstellar added a comment to D82847: [CMAKE] Fix 'clean' target not working.

This commit appears to be causing an error when I run CMake:

Aug 11 2020, 2:51 PM · Restricted Project

Aug 7 2020

tstellar added a comment to D85007: [PowerPC] PPCBoolRetToInt: Don't translate Constant's operands.

I can confirm that this patch also fixes the full test case.

Aug 7 2020, 3:52 PM · Restricted Project

Aug 6 2020

tstellar added a comment to D79279: Add overloaded versions of builtin mem* functions.

I thought part of the point of __builtin_memcpy was so that C library headers could do #define memcpy(x, y, z) __builtin_memcpy(x, y, z). If so, the conformance issue touches __builtin_memcpy as well, not just calls to the library builtin.

They would have to declare it as well (because C code can #undef memcpy and expect to then be able to call a real function), so the #define would be pointless. It doesn't look like glibc does anything like this; do you know of a C standard library implementation that does?

If we want to follow that path, then we'll presumably (eventually) want address-space-_overloaded versions of all lib builtins that take pointers -- looks like that's around 60 functions total. That said, I do wonder how many of the functions in question that we're implicitly overloading on address space actually support such overloading -- certainly any of them that we lower to a call to a library function is going to go wrong at runtime.

+@tstellar, who added this functionality in r233706 -- what was the intent here?

Aug 6 2020, 1:10 PM · Restricted Project, Restricted Project

Aug 3 2020

tstellar added inline comments to D85140: [RFC] Factor out repetitive cmake patterns for llvm-style projects.
Aug 3 2020, 10:51 AM · Restricted Project, Restricted Project

Jul 28 2020

tstellar added inline comments to D84405: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int).
Jul 28 2020, 4:48 PM · Restricted Project
tstellar updated the diff for D84405: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int).

Add volatile test.

Jul 28 2020, 4:47 PM · Restricted Project

Jul 27 2020

tstellar added a comment to D84405: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int).

Here is the assembly comparison for the 64-bit test I added between gcc and clang trunk + patch: https://reviews.llvm.org/P8227

Jul 27 2020, 6:19 PM · Restricted Project
tstellar added a comment to D84405: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int).

This is the test driver I used for testing. I compared the clang 11 + this patch with gcc 10 and saw no differences: https://gist.github.com/tstellar/80dae2ab8a18d810b10b8e42777f4fe4

Jul 27 2020, 6:10 PM · Restricted Project
tstellar updated the diff for D84405: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int).

Add 64-bit test.

Jul 27 2020, 6:05 PM · Restricted Project

Jul 23 2020

tstellar added a comment to D84405: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int).
In D84405#2170110, @vsk wrote:

How were you able to show that the specialized IRGen is equivalent to the generic kind? I tried doing this with direct inspection (https://godbolt.org/z/o5WEn3), but wasn't able to convince myself. In the past I used a test driver to compare the before/after compiler output -- you might find that useful (https://gist.github.com/vedantk/3eb9c88f82e5c32f2e590555b4af5081).

Jul 23 2020, 10:51 AM · Restricted Project
tstellar updated the diff for D84405: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int).

Remove stray comment.

Jul 23 2020, 7:18 AM · Restricted Project
Herald added a project to D84405: CodeGen: Improve generated IR for __builtin_mul_overflow(uint, uint, int): Restricted Project.
Jul 23 2020, 7:16 AM · Restricted Project

Jul 22 2020

tstellar updated the diff for D80395: HowToReleaseLLVM: Clean up document and remove references to SVN.

Add example for tagging the -init tag.

Jul 22 2020, 10:59 AM · Restricted Project

Jul 10 2020

tstellar committed rG1d68a780b34e: [clang-shlib] Don't link with static clang libraries (authored by tstellar).
[clang-shlib] Don't link with static clang libraries
Jul 10 2020, 2:29 PM
tstellar closed D82694: [clang-shlib] Don't link with static clang libraries.
Jul 10 2020, 2:28 PM · Restricted Project

Jul 9 2020

tstellar accepted D82078: libclc: Make all built-ins overloadable.

LGTM.

Jul 9 2020, 9:06 AM · Restricted Project

Jul 7 2020

tstellar committed rGef32c611aa21: [tests] Revert unhelpful change from d73eed42d1dc (authored by hubert.reinterpretcast).
[tests] Revert unhelpful change from d73eed42d1dc
Jul 7 2020, 2:31 PM

Jul 6 2020

tstellar committed rG70919a46facc: [tests] Speculative fix for buildbot breakage from c5f7c039efe7 (authored by hubert.reinterpretcast).
[tests] Speculative fix for buildbot breakage from c5f7c039efe7
Jul 6 2020, 3:43 PM

Jun 29 2020

tstellar accepted D82291: Make it possible for client code to consume CLANG_LINK_CLANG_DYLIB.

LGTM.

Jun 29 2020, 2:12 PM · Restricted Project