- User Since
- Sep 24 2014, 5:35 PM (278 w, 4 d)
Thu, Jan 23
Wed, Jan 22
Sat, Jan 18
Nov 8 2019
Nov 7 2019
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
Aug 12 2019
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
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.