- User Since
- Jan 2 2013, 1:50 PM (233 w, 2 d)
Addressed initial review feedback
Wed, Jun 21
Tue, Jun 13
Wed, Jun 7
Oops. I didn't mean to accept the revision yet.
It looks like a number of passes have this as a required analysis pass, and some assert that loops are in the simplified form. Can you verify that all passes which depend on this pass can also be skipped by opt-bisect?
Thu, Jun 1
Re-wrote the patch to move the isNoBuiltin checks into canConstantFoldCallTo and ConstantFoldCall.
Thanks for doing this!
Wed, May 31
Thu, May 25
Addressed review feedback
May 22 2017
Fixed LangRef spacing issues in more places
Addressed review comments
Updated to latest source base
May 12 2017
May 11 2017
A couple of things came up as I was preparing this for commit. They're pretty straightforward issues, so I'll just fix them in my sandbox before committing.
May 10 2017
May 9 2017
May 8 2017
Looks good to me.
May 5 2017
Looks good to me
May 2 2017
May 1 2017
Can you add tests for these changes? I think the attribute.ll and no-proto.ll tests in test/Transforms/InferFunctionAttrs would be the right place to add these. I'm not sure if the existing tests check all of the LibFunc calls or just a representative sample.
Apr 28 2017
Apr 24 2017
Apr 21 2017
I'm happy with this. Thanks for the improvements!
Apr 20 2017
Mar 23 2017
Mar 21 2017
Mar 13 2017
It looks like I need to rethink this.
Mar 7 2017
OK, so maybe that puts me back in the position of needing to find a way to conditionally add the MXCSR use/def information only when the strict semantics are required, in which case there would be no significant advantage to splitting the register as I'm proposing here.
Mar 6 2017
Feb 13 2017
Jan 17 2017
Is there anything left blocking this patch?
Jan 11 2017
-Consolidated examination of StrictFP node opcodes.
Jan 10 2017
-Combined uses of string literals for FP rounding mode and exception behavior.
-Removed extension to StringSwitch since it is no longer needed.
-Added documentation explaining that the rounding mode argument isn't used from the frem intrinsic.
Jan 5 2017
Jan 4 2017
Jan 3 2017
Dec 21 2016
It looks to me like you are probably correct about the intended mailing list post, but it's still not particularly helpful. It would be nice to have a reference to a primary source, but this is the best I could find:
Dec 16 2016
I have one nitpick about a typo in a comment, but otherwise this looks good to me.
Dec 15 2016
What do you think of this change instead?
Index: lib/Transforms/Scalar/LICM.cpp =================================================================== --- lib/Transforms/Scalar/LICM.cpp (revision 289480) +++ lib/Transforms/Scalar/LICM.cpp (working copy) @@ -124,8 +124,13 @@ }
Dec 14 2016
Sorry this is moving so slowly. I just reproduced the problem with the test file from your last comment. I'll take a closer look and see if I can understand what's going on.
Dec 12 2016
Dec 9 2016
I moved the isEHPad() check, as suggested.
Dec 8 2016
Dec 5 2016
Fixed typos and style issues.
Added FIXME comments as requested.
I see. I still think it's worth adding UnreachableDefault() instead of just a comment explaining that other values will assert/crash. I'm checking the legal values in the verfifier, so this shouldn't be an issue.
Nov 28 2016
I re-wrote the ISel code to introduce a pseudo-instruction for the strict variants of FP operations, which is mutated directly to a normal FP node just before instruction selection. I removed the SDNodeFlag extensions I had added in my original patch because they aren't needed in this implementation. Some variant of that code will likely need to be re-introduced at some point, particularly to handle FTZ rounding modes.
Nov 23 2016
Is flush-to-zero currently handled with function attributes?
Nov 22 2016
Nov 21 2016
Removed IntrInaccessibleMemOnly from llvm.assume.
Nov 10 2016
I added the IntrInaccessibleMemOrArgMemOnly property, and updated the llvm.assume intrinsic to use IntrInaccessibleMemOnly.
Nov 9 2016
Nov 8 2016
Nov 7 2016
Oct 25 2016
I'm trying to understand where the data structured entry gets removed when the pass is not skipped. I tried downloading the reproducer from the PR you mentioned, but I can't seem to get this to happen with that file and the command line you listed above. I have seen this problem before, but I'm having trouble making it happen now.
Oct 6 2016
The problem with adding more run lines is that if I understand this failure correctly, the test would fail if any of the run targets was missing from the build configuration. Long term, I think it would be nice if LIT had a way to selectively disable individual run lines based on the build configuration.
It looks like the explicit triples are being used in the tests in the non-arch-specific directory simply to force the tests to be run for both x86-64 and i386 targets. This is great for x86, but it means that these tests aren't run at all against other targets, even when another target is the default for the build. That seems bad.
Sep 27 2016
Sep 26 2016
I apologize for the delay. I forgot about this patch. I'll get it committed today.