- User Since
- Jan 4 2017, 12:11 PM (124 w, 13 h)
Thu, May 16
Thank you too!
Can you eventually push the patch for me? I think I no longer have commit access since the LLVM relicense stuff.
v3: - remove most of the LLVM IR
Wed, May 15
Thu, May 9
Yes, it did fix the problem.
Do you plan to backport to LLVM 8?
Wed, May 8
Tue, May 7
Mon, May 6
Tue, Apr 30
Fri, Apr 26
SI is still broken without this patch.
Apr 22 2019
Apr 21 2019
Apr 9 2019
This fixes the SI regression with RADV.
Thanks a lot Tim.
Mar 28 2019
This change breaks SI, at least with RADV.
Here's how to reproduce: ./deqp-vk --deqp-case=dEQP-VK.glsl.builtin.function.integer.bitfieldreverse.ivec3_highp_tess_control
Mar 26 2019
Thanks for the quick fix Matt!
This introduces a regression with this LLVM IR https://hastebin.com/yuzomezazi
It crashes inside llvm::SIInstrInfo::areLoadsFromSameBasePtr for some reasons.
Do you have the cmpswap fix somewhere?
Jan 9 2019
Thanks for the fix!
Dec 21 2018
Please have look at https://bugs.llvm.org/show_bug.cgi?id=40129
Dec 14 2018
Unfortunately, I can't get any LLVM IR because it crashes too early in the process. You can also reproduce the problem with RadeonSI btw.
Dec 13 2018
Yes, it does fix the issue. Thanks!
This patch breaks RADV (and probably RadeonSI as well). Here's a backtrace of the problem:
Dec 11 2018
Did you get a chance to look into this?
Dec 6 2018
This change breaks most of the subgroups tests with RADV (ie. dEQP-VK.subgroups.arithmetic.*).
Dec 4 2018
Oct 31 2018
This regresses the following tests on RADV:
Oct 17 2018
Thank you for this really important fix!
Aug 22 2018
Should I push the patch as is? Or does it need another revision?
Aug 21 2018
v5: rename MAX_COMMON_ADDRESS to MAX_AMDGPU_ADDRESS
Aug 20 2018
Both patches (r340171 and r340172) have been reverted with r340202 because it will be easier for a backport.
This new version squashes these two and includes the alias rules table fix (ie. out of bounds access).
v2: add a test with swapped parameters
v3: use static_assert()
Aug 17 2018
v2: add a very simple test for 32-bit addr space
May 25 2018
May 23 2018
May 3 2018
Without this patch, it appears to me that we are selecting
the wrong operand when inverting conditions. In the attached
test, it will select %tmp3 instead of %tmp4. To fix it, just
use 'A' as everywhere.
May 2 2018
Apr 25 2018
Any news on the revert? Thanks!
Apr 13 2018
Apr 9 2018
Apr 6 2018
Apr 3 2018
- init EnableDS128 in the constructor
Mar 30 2018
- use a return ternary operator
- fix feature format
- add small test load-local-f32-no-ds128.ll
Mar 29 2018
Mar 28 2018
Mar 15 2018
Mar 7 2018
- add a sanity check when a block is looping over itself
- cosmetic changes
- replace the LLVM IR testcase with a MIR one
- remove one unused variable in isLoopBottom()
- do not rely on block numbfer in isLoopBottom()
Mar 6 2018
v6: fix the multiple back-edges case and update the testcase
v5: run -dce to remove redundant phis
Mar 5 2018
v4: - run 'opt -S -deadarghaX0r -strip -strip-debug -strip-dead-prototypes -instnamer'
- remove RFC on the subject
v3: reduced testcase
Mar 2 2018
So, the expcnt(0) is generated because there is a buffer_atomic_add in that test case, which actually makes sense to me. Looks like this patch also fixes that case.
Oh, I thought expcnt() was for parameters export only, but it can be used for GDS instructions as well.
Here's a test case where a expcnt(0) is generated https://hastebin.com/uyuhabeqov.pl
This new revision attaches a LLVM IR testcase that reproduces the issue, not sure if the test can still be reduced compared to the original monster shader.
Feb 27 2018
Feb 6 2018
Oct 2 2017
Sep 22 2017
Mar 10 2017
v2: - preserve valye by using getNamedOperand()->getImm() instead
- add v_clamp_mac_to_mad test in clamp-modifier.ll
- add v_omod_mac_to_mad test in omod.ll
Mar 7 2017
Mar 6 2017
https://reviews.llvm.org/D26348 is probably better.
Or more generally, avoid sinking all functions declared with the convergent attribute.
Okay, I think the correct fix is to avoid sinking intrinsics if the convergent attribute is set.