- User Since
- Oct 9 2015, 4:06 AM (137 w, 1 d)
Thu, May 17
Wed, May 9
Hmm, you may have a point about trying to push the boundaries of what's possible by folding immediately. It would certainly be nice if it was possible.
Mon, May 7
Thanks. This change introduces more branches, but since it should only do so in an infinite loop it should be fine.
Fri, May 4
Should be good to go. Please add a reference to Mesa commit "amd/common: use llvm.amdgcn.wqm for explicit derivatives" to the commit message.
Thu, May 3
Thanks, this already looks very good. I do have some suggestions though.
So this does not cover all possible cases of "irreducible" infinite loops, e.g. consider the case with basic blocks A and B where both end with a conditional branch that can go to either A or B. I.e., there are no unconditional branches in the loop.
There are some unrelated changes, which I think should be mentioned in the commit description. Apart from that LGTM.
Wed, May 2
Good catch! I agree that this is a very useful change.
Mon, Apr 30
Is the default implementation really unable to do this? That seems a bit silly...
One typo, LGTM apart from that.
Fri, Apr 27
Thanks. I'll update here once I've finished all the testing.
Apr 26 2018
Consider what to do about integer values that don't fit exactly into a 'double'. This code will simply emit them as decimal integer literals, which JSON parsers are within their rights to round to the nearest double precision float, losing data. Some JSON readers (e.g. Python json.load) will deliver accurate integer values anyway, but it might be better not to rely on that, and instead output very large integers in some other form, such as a JSON object containing an identifying type field and two doubles whose sum is the desired integer, or a string representation of the integer, or both.
Apr 24 2018
Who is using this actually? Anyway, LGTM.
Apr 23 2018
This is hard to review because it contains a whole bunch of unrelated spelling changes. Do you think you could separate those out?
One bikeshed, apart of that LGTM.
Apr 20 2018
Apr 19 2018
One nit, LGTM.
Apr 11 2018
That seems reasonable.
Apr 10 2018
Apr 4 2018
Thanks, that should be useful. One typo :)
Apr 2 2018
Mar 27 2018
That looks more thorough than my quick hack. Dropping this one.
Indexed atomic ops are a good point. radeonsi and radv should be generating those as well for image atomics on texture buffers.
Mar 26 2018
Mar 23 2018
Since MsgPack is certainly not AMDGPU-specific, this should go into a target-independent utils directory, possibly lib/Support/.
Mar 20 2018
Thank you for making this change. The rest looks good to me, too.
Mar 19 2018
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.
Mar 17 2018
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.
Mar 14 2018
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.
Mar 9 2018
Update the docs, relax operands to !add, !and, !or in the same
way as shifts and add tests for it.