User Details
- User Since
- Jul 10 2012, 11:19 PM (445 w, 2 d)
Nov 11 2020
Nov 3 2020
Nov 2 2020
Do we need to handle the same pattern for non IN_REG variations?
Oct 29 2020
I'll be the dissenting voice: I don't think this is the right approach. "It's what gas does" is not a sufficient reason to break user code. I think a warning and *possibly* removing support some time well in the future is the right solution here.
Oct 28 2020
Oct 26 2020
Did the concept of using the static DAG not work?
Sep 22 2020
Nice catch, LGTM.
LGTM
Sep 21 2020
Sep 10 2020
Sep 9 2020
Sep 8 2020
Sep 2 2020
If the maps are typically small, would SmallDenseMap make sense?
Sep 1 2020
Aug 28 2020
Aug 27 2020
Aug 26 2020
Landed as a0aed80b22d
Aug 22 2020
Update for comments.
Aug 21 2020
Jul 9 2020
Sep 2 2019
Mar 22 2019
Mar 19 2019
Mar 18 2019
Use static
Add static
Mar 16 2019
Remove unit test for ThreadLocal as well.
Mar 15 2019
Getting the repository right.
Feb 20 2019
May 9 2016
Apr 13 2016
Apr 8 2016
I'm nervous about this change. The input code is denorm preserving on architectures that flush denorms, but the output may not be.
Apr 7 2016
I agree with Steve here. Even code that is built with -ffast-math has to live in a reality where NaNs, Infs, etc. are sometimes generated by external function calls, provided as user input, etc. It's critical that this code be able to filter out these invalid values, precisely because the body of the code will be optimized on the assumption that those values did not need to be considered.
Apr 1 2016
Mar 29 2016
LGTM
LGTM
Mar 21 2016
Needs doxygen comment.
Code change is fine, but I would like to see a doxygen comment for scalarizeVectorLoad()
Mar 1 2016
Hi Lang,
LGTM.
r262376
Ping?
Feb 27 2016
Added new CreateWithCopiedFlags() on BinaryOperator.
Feb 26 2016
Feb 25 2016
Feb 24 2016
Feb 23 2016
Feb 20 2016
Ok, I see what you're trying to get at, and I agree with your assessment that a it is removing a control dependence. Since it's specific to exactly the transform being applied, I think a little deeper explanation in the comment is merited.
Feb 19 2016
I don't agree with the new comments. If conversion does not remove any dependencies. It just changes their expression from control flow to predication, but they're still control dependencies in that they gate execution.
Feb 18 2016
I have convergent instructions that are essentially register->register arithmetic operations. I don't have any great dependence on them being rematerialized, but I wanted to point out that it's not inconceivable.
If-conversion doesn't change the control dependencies of the MIs that it moves. It just changes the expression of the dependency from expression via branches to expression via predication. Either way, the execution of the convergent op is still gated by the same set of expressions. Hence, I don't think any change is needed here.
Why is this needed?
My targets have convergent instructions that are rematerializable.
Feb 17 2016
LGTM.
Feb 16 2016
Do you have any suggestions on how a target might make a reasonable choice for the limit? Does the limit trend down as the size of the register file goes up?
Feb 12 2016
That's not correct for all platforms. Darwin, for example, uses NEON for floating point even in non-fast-math mode. The platform is simply defined not to support subnormals.
Feb 10 2016
That makes sense to me in principle, but I know nothing of why CWD is needed for (some form of?) DWARF generation at all.
Feb 9 2016
LGTM.
LGTM.
Feb 8 2016
Jan 29 2016
Functionality LGTM. I would add a comment at the use site of TokenFactorResult to point out that the walk is being memoized.
Jan 22 2016
Jan 10 2016
Jan 9 2016
I made an attempt to remove ownership from CompilerInstance, but ASTUnit has a massively complex relationship with FileManager, and foiled my attempt.
Jan 7 2016
I am not comfortable authoring a patch to do that, as I don't have a clear understanding of the clients involved, and have no means to verify its correctness.
Jan 6 2016
! In D15918#320308, @klimek wrote:
I understand - my question is, why not instead take away ownership from CompilerInstance?
Dec 10 2015
Your proposed fix seems conservatively correct to me. I'd recommend getting a review from one of the ARM maintainers, perhaps tnorthover?