[llvm-dev] noalias parameter attribute not currently exploited by alias analysis?
Alex Bradbury via llvm-dev
llvm-dev at lists.llvm.org
Sun Nov 8 08:30:09 PST 2015
On 2 November 2015 at 20:20, Alex Bradbury <asb at asbradbury.org> wrote:
> Can anyone give advice on how to interpret these 'Unknown' query
> results? It's also curious how about halfway through the basic block
> containing the unrolled loop the Unknown query results no longer have
> an associated basic block, despite the fact the code sequences are
> simply repeated.h
>
> Is there something obvious I'm missing here, or have I run in to a
> bug/limitation?
Hi Hal, list - I'd really appreciate some input here if anyone has a
moment. It seems there could be some real-world code missing out based
mainly on whether a function with restrict args is inlined or not?
To solve this issue for my use-case, I've written something for my
pass that's not too dissimilar to getUnderlyingObject(s) that will do
a better job of determining if a pointer is derived from an argument,
and added a bit of logic to filter out mayalias results where both
operations involve pointers derived from different noalias args. Just
generating the scoped-noalias metadata for all functions would
probably have been more straightforward, but unfortunately my pass is
implemented in an LLVM forked from before scoped-noalias metadata
support was introduced.
Thanks,
Alex
More information about the llvm-dev
mailing list