- User Since
- Jan 2 2013, 1:50 PM (249 w, 6 d)
Fri, Oct 6
Wed, Sep 20
This was committed as r313784. I put the wrong differential revision number in the comment for that check-in.
Tue, Sep 19
This is breaking buildbots for 32-bit targets because the offset in 'nullptr + int8_t_N' is being implicitly cast to an int. That makes the sizeof(offset) == sizeof(ptr) check turn out differently than my tests were assuming.
Sep 14 2017
-Changed GNU idiom from extension to warning.
-Updated to ToT.
Sep 13 2017
Does anything else need to be done for this to be ready to land?
Sep 5 2017
Aug 30 2017
Fixed value-dependent argument in isNullPointerConstant checks.
Added check for C++ zero offset in subtraction.
Added value-dependent test cases.
Refactored the GNU idiom check to be shared by Sema and CodeGen.
Refined the checks so that nullptr+0 doesn't warn in C++.
Added the zero offset qualification in the warning produced with C++.
Aug 29 2017
Added warnings for null pointer arithmetic.
Aug 25 2017
Aug 23 2017
My intention here was to make this as strict/limited as possible while still handling the cases of interest. There are two different implementations I want to handle. You can see the first variation in the __BPTR_ALIGN definition being added here:
Can you revert the white space changes in the places you aren't otherwise modifying? In general, you shouldn't make formatting changes outside of the parts of the file your patch is modifying. It complicates the version control blame process without adding a lot of benefit.
Aug 22 2017
I'm not sure why the svn attributes got attached to the file I added. I'll remove them before committing.
Can you put this off until the patch that Craig submitted in D36983 either lands or gets rejected? If that change goes through, you should be able to remove your modifications to X86ISelDAGToDAG.cpp.
Aug 18 2017
Aug 17 2017
Aug 15 2017
Aug 14 2017
Aug 4 2017
Could you also add a use of this new intrinsic to llvm/test/Verifier/fp-intrinsics.ll?
Jul 9 2017
-Addressed review feedback
Jul 6 2017
Jun 22 2017
Addressed initial review feedback
Jun 21 2017
Jun 13 2017
Jun 7 2017
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?
Jun 1 2017
Re-wrote the patch to move the isNoBuiltin checks into canConstantFoldCallTo and ConstantFoldCall.
Thanks for doing this!
May 31 2017
May 25 2017
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.