- User Since
- Mar 27 2015, 11:23 AM (194 w, 4 d)
Thu, Dec 13
Wed, Dec 12
That example cannot be expected to ever evaluate the expression as "1" -- it doesn't in GCC, nor should it in Clang. An asm constraint of "n" or "i" (but not, e.g., "nr") must require a constant expression, and evaluating the argument as a constant expression necessarily means always evaluating it to -1.
This seems like a good start, but not complete.
Tue, Dec 11
Thu, Dec 6
I'd note that most of this diff was not actually required to fix the issue. E.g, in the locations where an alignment is passed to allocation/deallocation functions directly, it is perfectly fine to use the __alignof value instead of the alignof value.
I'd note that this change isn't a necessary prerequisite to implementing the C++ feature -- FP math is already available in C11, and clang already implements it by lowering to cmpxchg. I'd be very skeptical of this addition, if you hadn't mentioned that AMDGPU supported it in hardware. AFAIK, there's no other ISAs that support atomic fadd in hardware. However, that AMDGPU does have hardware support seems like a sufficient reason to add support for it to LLVM.
Wed, Dec 5
Thus, I think that the simple expression will still work even with this use case.
Tue, Dec 4
Probably worth adding a range check on the membar operand when it's specified as an integer that it's actually in the range 0 <= val <= 127.
Seems odd, but this appears to match GCC's behavior, so, LG.
Mon, Dec 3
Since you've already submitted a fix to Boost, https://github.com/boostorg/build/commit/3385fe2aa699a45e722a1013658f824b6a7c761f, I think this is fine to remove.
Forgot to close with the commit, r347766.
Fri, Nov 30
Thu, Nov 29
Looks good, ship it.
Wed, Nov 28
Wed, Nov 21
BTW, I've tested this on Linux in both python2 and python3, but not on windows.
Nov 16 2018
Hopefully resolved the python3 compatibility with r347113.
Nov 9 2018
Nov 7 2018
Nov 6 2018
Added sccp testcase.
Let's submit this soon, even if it will be further edited.
Picking this back up again...
Rebased onto current head, no changes.
Also remove and recreate the branch in a single commit if using
Nov 1 2018
Oct 30 2018
Oct 26 2018
Oct 19 2018
Oct 18 2018
Oct 14 2018
Address most comments.
Oct 12 2018
Oct 10 2018
Oct 9 2018
Given that there's no technical reason for the compiler to prohibit this (it was just clang trying to diagnose a probable user-error, which turns out to not be as probable as ), this seems like the right solution to me.
Oct 5 2018
Oct 4 2018
Just noticed I forgot to commit this. Will do so now. :)
Oct 2 2018
Sep 27 2018
Sep 18 2018
I'd prefer it to more strongly indicate that the IR-level LL/SC lowering is broken and should not be used in the future, and hopefully will be removed once targets have migrated off of it.
Straightforward enough; LG.
Final update looks good as far as I can tell.
Aug 29 2018
Aug 28 2018
A revert won't apply cleanly by now, so probably best to make a review for it. I suspect it's simpler to just delete the code as it is now, rather than try to actually do a git revert.
Aug 26 2018
It's possibly only theoretical at the moment, since I don't know if anything both supports this and is little endian, but --
On a little endian system, will the registers be swapped; that is, would ASR22 hold the 32 LSB instead of ASR23?
Dare I ask -- are you fixing them because you're testing with -verify-machineinstrs and fixing the failures, or because you actually want it for something?
Seems unclear to me that the "more than one use" bit is the right assumption. But sure, let's go with that for now.