- User Since
- Sep 24 2014, 5:35 PM (264 w, 2 h)
Thu, Sep 26
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.
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?
Aug 1 2018
Merged as r338610
Merged without the test. thanks