♟ tstellar

Another attempt to fix this that depends less on the build directory.

lit: Bump version to 0.10.0

In D65763#1616275, @hans wrote:

In D65763#1615311, @tstellar wrote:

We also need to bump the version in the release/9.x branch to 0.9.0.

Done in r367992, and I've made a note for myself to include it in the major version bump next time.

What made you notice this, i.e. where does this version number matter?

lit: Use a License classifier that pypi will accept

Make helper function members of CombineInfo class.

Address review comments.

Update offsets for the raw and struct intrinsic variants.

Change license classifier to: OSI Approved :: Apache Software License
as suggested by Joerg on IRC.

Add 8.0.1 clang-tools-extra docs

Add 8.0.1 libcxx docs

Update latest release to 8.0.1

Add 8.0.1 clang docs

We also need to bump the version in the release/9.x branch to 0.9.0.

Remove accidental version bump.

AMDGPU/LoadStoreOptimizer: Set the correct offset whem merging MMOs

Add links to 8.0.1 binaries

AMDGPU/SILoadStoreOptimizer: Make some functions const

Add support for the raw and struct intrinsics.

AMDGPU/LoadStoreOptimizer: combine MMOs when merging instructions

Ok, thanks for the info. I will drop this patch.

github-upload-release.py: Fix script name in examples

Add github-release.py script

Add 8.0.1 to the release page

We could do the same for the raw and struct variants of the intrinsics, but I wasn't sure exactly what conditions had to be met in order to guarantee that we had a constant offset.

Ok, this seems fine. Those types aren't really use much.

Which types are regressed?

Add links to 8.0.1 sources

Add 7.1.0 release to index.html

I'm in favor of this, but we should make sure there is documentation telling users how to explicitly choose the python version they want. I'm also curious, how does cmake determine which version to use if more than on interpreter is found?

In D64841#1589092, @hans wrote:

My initial thought when I saw the filename was that this was a github version of test-release.sh. Which we'll need too, but it's not this one :-) What do you think about renaming to github-upload-release.py, or something else that has "upload" in the name to make it more explicit?

This is super cool! I just looked at https://github.com/llvm/llvm-project/releases

Should we be using this to host binaries from now on, and link to them from http://releases.llvm.org/ (ah, I see you did this for 7.1.0 already; I guess I'm not keeping up).

Rename script and add documentation for how to obtain a github token.

[OpenCL] Make TableGen'd builtin tables and helper functions static

LGTM, do you think we'll need new register classes for the 32-bit boolean values?

This looks OK to me, but I'm not as familiar with how this will impact SDAG. Might want to have someone else take a look too.

Add link to GitHub status page

cmake: Fix install of libclang-cpp.so when LLVM_INSTALL_TOOLCHAIN_ONLY=ON

tstellar (Tom Stellard)
User

Projects

User Details

Recent Activity
View All

Tue, Aug 13

Thu, Aug 8

Wed, Aug 7

Tue, Aug 6

Mon, Aug 5

Thu, Aug 1

Wed, Jul 31

Tue, Jul 30

Mon, Jul 29

Thu, Jul 25

Wed, Jul 24

Tue, Jul 23

Mon, Jul 22

Jul 19 2019

Jul 17 2019

Jul 16 2019

Jul 15 2019

Jul 12 2019

tstellar (Tom Stellard)User