- User Since
- Oct 9 2015, 4:06 AM (128 w, 1 d)
Since MsgPack is certainly not AMDGPU-specific, this should go into a target-independent utils directory, possibly lib/Support/.
Tue, Mar 20
Thank you for making this change. The rest looks good to me, too.
Mon, Mar 19
Address minor review comments and add a new test case that demonstrates
the inconsistencies in name resolution.
Is that compiler really supported? Look at this:
void operator delete(void *) = delete;
It's been there in the code since early 2015. The bitwise OR on ELF::xxx has been there even longer.
Sat, Mar 17
For the AMDGPU imm tests, you could please change the affected ones to operate on i32/i16 instead, so that the result uses v_add_u32? Thanks!
Is this related to D40547? I sent a ping on that, but no response...
I don't think we should add workarounds for broken compilers.
Wed, Mar 14
Updating with a cleanup that I missed.
Better error messages.
More explicit error message on undefined reference.
We need tests for the store case as well.
Fri, Mar 9
Update the docs, relax operands to !add, !and, !or in the same
way as shifts and add tests for it.
Clarify docs, add test cases.
Okay, makes sense.
Wed, Mar 7
Have you tested this on real hardware? I remember reading that there is a hardware bug on gfx7 with this instruction. The bug may apply only to early gfx7 chips.
Add !ne as well
Improve parser error messages and add missing CHECK: in tests
Clarify the docs
Use folding set, change docs, and improve parser error messages
Tue, Mar 6
I think I'm partially changing my mind on this. There are some indirect self-references already happening in existing .td files, and after looking at a number of different approaches I'm inclined to add something like your change here, suitably adapted. A side benefit is that the rule in LangIntro about how !cast works becomes simpler and less dependent on the implementation details of variable resolution.
Mon, Mar 5
I haven't yet had the time to fully grok what's going on here, but I suspect this code is fundamentally broken because the whole assumption of having a single loopBottom is wrong. It happens to be true for structured loops with non-uniform control flow, but when there's uniform control flow, there may well be multiple back-edges. What happens in those cases?