- User Since
- Sep 24 2014, 5:35 PM (247 w, 6 d)
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
Jul 28 2018
Jul 27 2018
I've been using a version of this locally and it fixes most, but not all tests with char/uchar/short/ushort kernel arguments.
I thought that fixing the hardcoded alignemnt=4 would help, but it's not enough.
It'll need to be handled separately.