Should we also emit a note how to silence it, eg. swap xor operands or add parentheses around 2/10 ?
In future, DAGCombine could do the check to see whether c1 fits into an add immediate, which might simplify more targets hooks than just RISC-V.
Well, yeah, that's the thing
Thanks, looks fine now (with fixed regression).
Thanks, you fixed it!
Fri, Jun 14
Oh, no. Still there :((
Rebased. Moved to DAGCombiner and fixed regression in jump_sign.ll.
This might not be currently ideal recommendation since std::copy produces memmove with -O3.
isDeclarationStatement() returns true for attribute((fallthough)) ;
Thu, Jun 13
Please fix the "summary" to include the full expected commit message.
I had the following comment on the original revision:
If both the caller and callee are sret, do you need to check that the sret argument is the same? Consider something like tail call void @f(%struct.foo* noalias sret @aa) nounwind.
Did this ever get fixed?
Fixed EOF in test case.
Now patch only adds _attribute__ ((fallthrough)) support. Parsing will be hopefully solved in second patch.
One more test added.
Addressed some review notes. Thanks.
__block y = 7;
Revert deleted testcase.
Since this patch was abandoned, I will try to continue it here: https://reviews.llvm.org/D46262
Reopened, since original D45653 was abandoned.
Updated tail opts with testcase from @Jim. Thanks.
Wed, Jun 12
Handle uitofp better.
Preserve test logic in tail opts.
Fixed all undefs.
FIxed review notes by @rnk. Thanks.
Revert unneeded formating changes.
More check for exponent int bitwidth.
Added more tests.
Rebased to master.
Some more things to do, or is it fine now? :)
Attached forgotten tests
Warn in more cases. Added many new tests.
I will work on this after we land https://reviews.llvm.org/D63139.
Tue, Jun 11
Thanks. Are you still working at this?
I know this is a little late, but is the second run line of test/CodeGen/AArch64/arm64-popcnt.ll correct? If I build with -DLLVM_TARGETS_TO_BUILD=AArch64;X86 I get an error. As far as I can tell, using grep -l 'RUN.*triple=armv8' -R ../test/ armv8a is dealt with as an ARM target, not an AArch64 one, which is weird in and of itself.
Mon, Jun 10
do you know why this warning is not on by default? :/
2 questions, since i've read through the diff:
- will this pick the smallest cost, or the first negative cost?
- is this missing some abstraction? maybe InlineResult Result should be some wrapper that should be assigned-to, that will internally only accept the new value if it's better than what it currently has,
- Not the smallest cost, but the first negative result with its message.
- I think such an abstraction would not be much shorter: Result = InlineResult::FirstNegative(Result, expression)
If you take libcxx code for std::merge and compile it with GCC, is it faster? If not much, or even worse than Clang, I see no reason why not to improve it in libcxx's codebase.
Transform only when full fast math mode.
You can check and take tests from my older patch https://reviews.llvm.org/D58878
Removed unrelated change
Adding @RKSimon as a reviewer since he recently fixed some bugs which GCC's -Wint-in-bool-context caught.
Sun, Jun 9
There were discussions about integer min/max intrinsics some years ago but stalled .. old motivation cases + our new motivation cases should indicate that integer version of max/min intrinsics are worth.