- User Since
- Jan 2 2013, 1:50 PM (224 w, 5 d)
Fri, Apr 21
I'm happy with this. Thanks for the improvements!
Thu, Apr 20
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.
Aug 18 2016
Jul 26 2016
Jul 13 2016
Jul 6 2016
Adding a test.
The purpose of this change was to avoid a case where the old algorithm was getting into an infinite loop moving different blocks to the end of the function. As I recall, this situation arose because the old code was sometimes mistakenly deciding that control flow could fall through from a normal block to an EH block that was reachable from that block via an exception. If multiple EH blocks were reachable, the old code wanted to place each of them immediately after the block from which they were reached.
Jun 8 2016
Jun 7 2016
Jun 6 2016
You definitely could (and I think should) do this with opt-bisect.
May 26 2016
Implemented suggested revisions.
Sounds good to me. I'll upload changes for final review as soon as my local testing finishes. It looks like I still need to take that line out of the optnone-llc test because the pass aborts for other reasons before calling skipFunction. Otherwise, this looks like a very clean solution.
May 23 2016
Refactored implementation as suggested.
May 19 2016
May 18 2016
May 3 2016
Apr 27 2016
Apr 26 2016
Added code to check of opt level != None before adding the PPCVSXFMAMutate pass
Made the PPCVSXFMAMutate pass skippable
Removed skip check for NVPTXLowerKernelArgs
Removed skip calls from passes that are run at -O0
Moved skip checks behind other single variable conditions