- User Since
- Apr 5 2018, 5:18 PM (167 w, 4 d)
I am quite skeptical how useful this can be in practise. Any motivation examples from real world codes/benchmarks?
Fri, Jun 18
Tue, Jun 15
Sat, Jun 12
Maybe this caused https://bugs.llvm.org/show_bug.cgi?id=50550. Could you check and comment it?
Thu, Jun 10
Wed, Jun 9
Ok thanks for info. We should follow gcc in this case.
gcc also ignores it?
Mon, Jun 7
Sun, Jun 6
The new results look fine.
Sat, Jun 5
Fri, Jun 4
Thu, Jun 3
Wed, Jun 2
Commited without approval?
Tue, Jun 1
Mon, May 31
Ok, this looks fine now I think.
Sun, May 30
What are the latest compile time data for this patch?
Sat, May 29
Fri, May 28
Since instcombine is currently only user of emitCalloc, so after you commit this patch, please delete AttrsList parameter from emitCalloc (and adjust this new callsite in DSE) together with removal of this transformation from instcombine.
Wed, May 26
And remove transformation from instcombine?
Tue, May 25
Would it be fine to revert this for now to work out the kinks?
Mon, May 24
And there is something weird in terms of cost modelling between vectorizers.
Can this patch optimize code from comment #4 in https://bugs.llvm.org/show_bug.cgi?id=47491 ?
May 22 2021
Ah right:) I understand now.
May 21 2021
May 20 2021
Also fix a few places where this warning is correctly triggered.
getting this all right and enabled by default with the first commit is probably not achievable
May 19 2021
What about C-ray? Does function specialization help?
If we improved the robustness of our other optimizations w.r.t. vector instructions, we'd probably be a lot less sensitive to the proposed pass reordering.
This, I think, also relies on the loop vectoriser which seems more powerful than SLP vectorisation currently.
Instead of removing early full unroll pass (see @nikic's concerns), couldn't we run loop vectorizer before full unroll pass?
I don't have suggestion on how to move forward *this* patch, because I think it's fundamentally the wrong direction to take.
May 18 2021
May 16 2021
May 15 2021
hold off this patch.
If that's implemented in GCC then this change here to build with -fno-semantic-interposition would mean that the test failures seen in D102090 would resurface.
May 14 2021
Any testcase to ensure that passes together now produce what you want?
It further requires us to split the current pass into an analysis one and a transformed
May 13 2021
I think we could limit the numbers of function specialized.
Maybe additional info about upper bound (if dst or src is local/global buffer; getDerefenceableBytes API) may be interesting too?
I cannot figure out how to make -fno-semantic-interposition specific to llvm/ and clang/.
I think it would take a long time to tune the heuristics and the cost model may be changing during the evolution process.
absolute numbers being small: do you have any insight into whether the impact is expected to be less on larger benchmarks/binaries?
Manually tagging those arguments with an attribute in exchange for guaranteed specialisation when they're constant would be high value, even without any heuristics to automate the decision.
May 12 2021
You dont have to use -Wno-…
Whether we want to run this transformation on newer archs - as you said, it brings us nothing, so atleast we should check it is free in terms of compile time in the backend.
May 11 2021
What about IR backward compatibility?
Can you try this patch with http://llvm-compile-time-tracker.com/ ?
May 10 2021
May 9 2021
What about DeadStoreElimination ? It can also merge stores.. maybe dse needs similar fix.
This could help with https://bugs.llvm.org/show_bug.cgi?id=50105 ?
May 7 2021
it seems like we dont specialize std::find to use memchr if possible?
Just curious, why you cannot use:
Hello, some days ago I was looking at it.
May 6 2021
Can you collect some performance stats?
- testsuite/spec benchmarks/etc?
May 4 2021
Moved to InstCombine.
// FIXME: This should be in InstSimplify because we're replacing an ...
No strong opinion, but everybody should agree.