- User Since
- Jun 6 2014, 4:30 PM (263 w, 4 d)
Sun, Jun 23
Fri, Jun 21
Thu, Jun 20
it seems like there are a lot of cases where SCEV's exit count reasoning is stronger than it's isKnownPredicate reasoning.
Mon, Jun 17
I don't have opinions on this, but Philip might have comments around whether this is okay for GC pointers.
Fri, Jun 14
Thu, Jun 6
I should just include the resultng test change in this commit and not worry about it.
May 15 2019
May 14 2019
May 9 2019
Thanks for the quick fix!
May 8 2019
May 7 2019
May 6 2019
Only minor nitpicky comments, will LGTM once these are fixed.
May 5 2019
LGTM. If possible (and you haven't already) try bootstrapping clang in a few configurations to double check things are okay.
May 4 2019
I'm not sure if the current fix is correct. I'd suggest doing one of the following:
Apr 28 2019
and as I found out also stack overflows
This change in isolation LGTM (modulo some minor comments inline) -- at the very least having separate umin / smin nodes makes min expressions more readable (as demonstrated by the updates to the test cases).
Apr 27 2019
I got confused on the terminology
Apr 18 2019
Apr 13 2019
Apr 10 2019
Apr 4 2019
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?
Apr 2 2019
Apr 1 2019
Mar 31 2019
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:
Mar 29 2019
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!