[LLVMdev] question about enabling cfl-aa and collecting a57 numbers

[Daniel Berlin]

George, given that, can you just build constexpr handling (it's not as easy
as you think) as a separate funciton and have it use it in the right places?

FWIW, my current list of CFLAA issues is:

1. Unknown values (results from ptrtoint, incoming pointers, etc)  are not
treated as unknown. These should be done through graph edge (so that they
can be one way, otherwise, you will unify everything :P)
2. Constexpr handling

^^^ These are correctness issues. I'm pretty sure there are a few more but
i haven't finished auditing
3. In a number of places we treat non-pointers as memory-locations and
unify them with pointers. This introduces a lot of spurious aliasing.
4. More generally, we induce a lot of spurious aliasing through things at
different dereference levels.  In these cases, one may to the other, but,
for example, if we have a foo***, and a foo* (and neither pointers to
unknown things or escapes), the only way for foo *** to alias foo* is if
there is a graph path with two dereferences between them.
We seem to get this wrong sometimes.




On Sun Jan 25 2015 at 6:44:07 PM Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Sun, Jan 25, 2015 at 6:37 PM, George Burgess IV <
> george.burgess.iv at gmail.com> wrote:
>
>> > Fixing that still gives a wrong result, i haven't started to track
>> down what *else* is going on here.
>>
>> Running with the attached diff + a modified buildGraphFrom to handle the
>> constexpr GEPs, we seem to flag everything in test2.ll (conservatively)
>> correctly.
>>
>> Is `store` the only place we can expect to see these constexpr analogs,
>> or is just about anywhere fair game?
>>
>
> Any Value can be a ConstantExpr, so all operands to instructions are fair
> game.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150126/f9a5490a/attachment.html>