User Details
- User Since
- Sep 24 2015, 3:41 PM (277 w, 5 d)
Oct 7 2019
Aug 1 2018
PING
Jul 13 2018
PING
Jun 26 2018
Jun 8 2018
Jun 7 2018
It was requested by Quentin in https://reviews.llvm.org/D29862
PING.
Jun 1 2018
May 31 2018
PING
May 24 2018
PING
May 16 2018
PING.
May 15 2018
May 2 2018
PING. The change does not change code in spec2000/spec2006. However, it prevents compile time hangs in some corner cases.
Apr 30 2018
Apr 26 2018
Addressed comments. Made heuristic more precise.
Apr 25 2018
A kind of. However the patch allows >16 and < 256 on the first level.
Apr 24 2018
Use APFloat instead of new class.
Mar 22 2018
Mar 21 2018
Mar 14 2018
LGTM.
Mar 6 2018
Mar 2 2018
Feb 26 2018
PING
Feb 12 2018
Feb 9 2018
Leave only zero check and move it to an earlier stage.
Jan 29 2018
It is not obvious that constants in address can somehow hurt performance.
I'll run the patch on the benchmarks I have. However I believe performance issue in PR35861 is about complicated addresses which limit execution ports for stores.
Jan 26 2018
Jan 10 2018
Jan 4 2018
PING2
Dec 28 2017
PING
Dec 26 2017
Dec 21 2017
To be more precise NaryReassociation works that way:
r0 = v * 16
r1= r0 * 0
r2 = r1 * 1
Dec 20 2017
Nov 3 2017
Nov 2 2017
Nov 1 2017
Oct 31 2017
Oct 5 2017
Sep 26 2017
Sep 1 2017
Aug 28 2017
Hi Max,
Aug 25 2017
PING.
Aug 18 2017
Aug 7 2017
Aug 4 2017
Aug 2 2017
Other tests that have difference in binaries got the same performance.
Interesting, given we were generating invalid code, what changed there?
Aug 1 2017
Jun 12 2017
Jun 6 2017
Jun 5 2017
Jun 2 2017
May 31 2017
PING
May 26 2017
How do you think which way we should follow?
Or we can leave regression as is as Solution Cost is better and therefore it is not a problem of newly implemented NarrowSearchSpaceByDeletingCostlyFormulas()?