- User Since
- Jun 6 2014, 4:30 PM (254 w, 9 h)
Thu, Apr 18
Sat, Apr 13
Wed, Apr 10
Thu, Apr 4
Ah thanks, I was missing the global nature of physical pointers. I couldn't find this described anywhere (besides some of those things mentioned at a tutorial at EuroLLVM). If this is not described anywhere, do you think it would make sense to add it to the AliasAnalysis documentation page, for example?
Tue, Apr 2
Mon, Apr 1
Sun, Mar 31
I'm not sure about this. You could have:int32* ptr0 = malloc(4); int32* ptr1 = malloc(4); if (ptr0+1 != ptr1) return; int32* ptr = (int*)(int64)(ptr0+1);
in which ptr would alias ptr1. But if you transform ptr to ptr0+1 then it would not alias ptr1.
I am probably missing something, but I am not sure how such a case would be possible with this patch? It specifically looks for a inttoptr(and(ptrtoint, C)) sequence, where C is such that the (logical) destination of the pointer remains unchanged. Unfortunately I do not think the LangRef is clear about 'irrelevant' bits in pointers (due to alignment or address spaces)
Things that are UB in C++ are not necessarily UB in LLVM. For instance you could capture a pointer by doing something like this:
Fri, Mar 29
Fix bug: when trying to look up the smax/umax SCEV again (after simplification) we can't use the older ID since it was computed based on the unsimplified operands.
Sorry, this is buggy, one moment.
Mar 20 2019
Mar 19 2019
Mar 18 2019
This change needs a test, as Roman said.
Mar 16 2019
Ok, looks like we're somewhat sloppy with our choice of insertion points here (and it should not be incumbent on you to fix this). Can you please add a comment that mentions that this is due to indvarsimplify?
Mar 14 2019
Apologies for the late review Warren.
Mar 13 2019
langref part seems to be missing.
Mar 11 2019
Mar 6 2019
- Address review comments
Mar 5 2019
Mar 4 2019
Rebase on trunk.
Matt, I noticed a necessary change I had to make before landing this separately.
I didn't notice this because I was initially testing this combined with some
Add unit test
Thanks for the explanation!
Mar 3 2019
Propagate only correct FP fast-math flags.
Mar 1 2019
The change itself looks fine to me, but I'm a bit worried about the test changes. Is it possible that the tests were checking certain the correctness for certain expressions that we no longer check because these happen to be expensive? If that's the case maybe we should add a debug flag that disregards the "is expensive expansion" check to make sure the the same code paths remain tested?
Feb 19 2019
Feb 11 2019
Feb 6 2019
Feb 4 2019
Feb 1 2019
I don't think we can fold undef within SCEV since SCEV's choice for undef might not be what other transformations choose. For instance if you have a loop:
I'm okay with the direction, but I'm also worried that this breaks some subtle invariant between SCEV and SCEVExpander. Have you tried bootstrapping clang with this change to see if that shakes out any issues?
This is fine, but IMO mapping them to undef feels cleaner conceptually.
Jan 25 2019
Jan 24 2019
Jan 21 2019
Jan 16 2019
Jan 10 2019
Jan 9 2019
I didn't carefully review the MSSA specific stuff since you're the domain expert here. I do have some general comments.
Oct 22 2018
Oct 15 2018
Oct 10 2018
Oct 8 2018
Oct 5 2018
+1 on the general idea, though like Florian I too think this is too expensive for a normal debug build. How about putting it under a flag (putting under EXPENSIVE_CHECKS requires a recompile right?) that can even run on release builds? That flag can even be enabled by default on EXPENSIVE_CHECKS builds.
Sep 24 2018
If I get no results, at least 1% RSS is an upper bound on increased LTO memory usage. I'm happy to trade that for 40% shorter compile time of the slowest TUs in clang.
The downside is that Instruction grows from 56 bytes to 64 bytes, and I don't have a good way to measure what that costs in practice.