[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