[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments

Dan Gohman dan433584 at gmail.com
Thu Jan 17 11:00:55 PST 2013

On Wed, Jan 16, 2013 at 2:39 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Wed, Jan 16, 2013 at 12:53:55AM +0100, Joerg Sonnenberger wrote:
>> Let's come back to this. The attached patch decouples InstSimplify from
>> the alias analysis and provides the conservative logic for when pointers
>> are not equal.
> Let's take the version with the cleanup from IRC. *sigh* Dealing with
> too many copies.

One of InstructionSimplify's strengths is that it is simple. Having
constraints where its users have to know which calls are safe in which
contexts would make it tricky. Having a flag you pass in to tell it
what kind of context you're calling it from would complicate it. And,
we've had numerous (on and off-list) emails just to understand the
problem to the extent that we do now, and I'm still not fully
convinced we understand it fully.

How important is this optimization? Do you have real-world code where
it matters?

Intuitively, it seems that the kind of pointer comparisons you're
aiming at would be uncommon. Code authors can avoid them for the same
reason that you think the compiler can eliminate them (except that a
code author typically doesn't have to worry about their own code being
pathological, while the optimizer does). I'm aware that code can often
look pretty surprising after macro expansion and inlining, but anyone
choosing to add restrict to their pointers is obliged to be fairly
careful about how such pointers are used.


More information about the llvm-dev mailing list