- User Since
- Apr 6 2017, 8:36 AM (156 w, 4 d)
Jan 21 2020
Ping. I don't see any comments that require action on my side.
Jan 15 2020
Remove target datalayout string from the test
Jan 14 2020
Pass tripple/target-cpu via opt's --triple/--mcpu options
Dec 9 2019
Probably not too much important because should be handled by the vector predicated instructions/intrinsics, but still
Oct 10 2019
Oct 9 2019
Aug 1 2019
Thanks for working on this! I'm really interested in using this functionality so here are some comments on the main interface header.
Aug 30 2018
Aug 28 2018
Aug 27 2018
Aug 20 2018
Aug 1 2018
- Address Erich's comment + clang-format.
Jul 31 2018
Jul 26 2018
to change this logic if there is a consensus on how inlining should be handled in case of "null-pointer-isvalid" attribute mismatches.
Jul 25 2018
Note that, I am expecting that functions with alwaysinline attribute should still get inlined. If that happens and caller does not have this attribute, then optimizer is free to remove the checks.
Jun 26 2018
Jun 25 2018
May 24 2018
Apr 24 2018
Apr 23 2018
Mar 21 2018
The test passes without that "-O2" but I'm not sure why it was there originally...
Mar 20 2018
Mar 16 2018
Mar 15 2018
Improve some comments.
Mar 14 2018
Mar 1 2018
Feb 27 2018
Feb 15 2018
Feb 14 2018
I might be missing something, but why don't we enable DT back in LVI after the JT pass finishes and flushes the DDT? Is it possible that we end up with disabled DT *after* the JT?
Feb 13 2018
Jan 30 2018
Jan 29 2018
I've just submitted https://llvm.org/PR36133 containing a testcase that show how JumpThreadings miscompiles (without crashes) the code due to DomTree not being updated between the iterations of JumpThreading itself.
Jan 26 2018
Use regsOverlap instead of isSuperOrSubRegisterEq.
Jan 25 2018
Indeed, on X86 checkRegistersAlias is just isSuperOrSubRegisterEq (although the former would be the right choice if that was not so :)).
Comment was added - thanks for the exact text!
Jan 15 2018
Jan 11 2018
- Move TODO from the test to the actual code.
Jan 10 2018
Dec 12 2017
In D40524#951832, @andrew.w.kaylor wrote:
I'm not terribly familiar with MIR as it appears in a test like this, but I can't see any reason that your proposed testcase would be invalid. I do think it's extremely unlikely to arise in actual generated Machine IR, since we hardly ever use the 8-bit high registers. What I'd like to do is commit the change from this review as is, and file a new Bugzilla report to track the 8bit_hi issue. Does that sound reasonable to you?
Nov 30 2017
I'm not sure if the following is possible/legal but it fails even with this patch:
Nov 28 2017
Sep 19 2017
Sep 14 2017
There is a typo in the summary: "were are", "make award".
- Address review comments.
Sep 12 2017
Sep 7 2017
Jul 27 2017
Rebased to updated D35002 where fptosi tests were added. That also included re-base to the current master.
No changes in the instcombine results for these added tests though.
Added mixed clamp tests with fptosi.
Jul 5 2017
Compare types instead of their sizes to decide if CastInst is needed.
Rebase onto D35002.
Jul 3 2017
Hi @efriedma, original commit caused the failure under UBSan. The latest uploaded revision fixes it.
Can you please take a look and say if it's ok?
- Fix UBSan error after D33186/r306525.