Fri, Nov 8
Thu, Nov 7
I've set up an appveyor build to replace this. The added benefit is that the appveyor stores built libraries as artifacts that can be downloaded.
The downside is that I wasn't able to restrict builds to libclc changes so it's only enabled for my fork of llvm-project.
Oct 16 2019
Sep 26 2019
Aug 19 2019
sorry for the delay. I fully understand the need to reduce the number of options. Having always used SHARED_LIBS build I remember weekly shared build breakages.
That said, forcing everyone to build one huge library effectively makes debug builds unusable in any practical way.
Having a usable debug build would also obsolete the with_asserts option.
What is the use-case of one big shared lib that split libraries can't do?
Aug 13 2019
I want to dissect this a bit.
I am in favour of adding a user-facing option to disable generating this duplicate library for users that don't need it
Why do you call this duplicate? It is unique. There is no other library in the clang build that serves the role of this library.
Aug 12 2019
I think you and I disagree here. General developer workflows don't need to include building all for every minor change. In my normal workflow I just re-run check-llvm or check-clang over and over again, only building the all target before I post a patch. With that workflow I only build the library once per-patch to ensure that it builds. Which is exactly the goal of not having it be included.
I generally am not a fan of adding more and more options. As long as you're not linking the library it won't be generated by any of the check targets. With the llvm dylib we've had many issues over the years where changes to LLVM break building the dylib and many developers don't build it, so we have to wait for a bot to catch it. Making the clang dylib build as part of all in every possible build configuration is a recognition that this is something we ship and we should ensure works.
Aug 11 2019
Aug 5 2019
May 9 2019
Are you sure this was enabled by default before? (cl::init(true))
I've traced regressions in r600 and amdgcn to this patch.
While both look like backend bugs, the commit message says NFC.
Mar 27 2019
Mar 13 2019
Jan 14 2019
I modified some AMDGPU tests to track more registers where possible as @jvesely suggested, and I added some missing new relevant generated instructions (BFE_INT).
Jan 12 2019
Jan 8 2019
sorry for the delay. afaik r600 does not do any special handling wrt to coalescing loads. There is a general load/store vectorizer by @arsenm, so it looks like this patch is interfering with it, but I'd expect the same to happen for GCN as well.
I'm OK with these pessimizations, R600 loads/stores have bigger problems.
Jan 7 2019
Nov 27 2018
Nov 10 2018
Nov 3 2018
Sep 29 2018
Sep 15 2018
Aug 21 2018
Aug 20 2018
Please add a reference to llvm bug https://bugs.llvm.org/show_bug.cgi?id=38113
as well as correct "Differential Revision" tag when committing.
This patch no longer applies
NACK. This patch is clearly wrong.
MAX_COMMON_ADDRESS is used in AMDGPUAAResult::ASAliasRulesTy::getAliasResult to filter indices to the ASAliasRules table which is 6x6. Allowing address space 6 leads to out of bounds access to the array.
Aug 7 2018
rename numbered operations
Aug 3 2018
Can we just have the fix in, and worry about optimizing i16 extends later?