[llvm-dev] RFC: New function attribute HasInaccessibleState

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "James Y Knight" <jyknight at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org>
> Cc: "Vaivaswatha Nagaraj" <vn at compilertree.com>
> Sent: Friday, December 4, 2015 1:09:37 PM
> Subject: Re: [llvm-dev] RFC: New function attribute HasInaccessibleState
> 
> On Dec 4, 2015, at 12:42 PM, Hal Finkel via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >>>> In the case of user-defined allocation functions, the
> >>>> definitions
> >>>> for those functions are available
> > 
> >>> Are they? probably not unless you're in an LTO build.
> > 
> >> Yes, I'm assuming an LTO build.
> > 
> > The concerns around LTO here, while legitimate, apply only to a
> > very-specific kind of LTO: An LTO which includes the definitions
> > of the libc. This is actually quite tricky to support,
> > semantically, and already breaks our malloc aliasing assumptions.
> > There are many legitimate uses of LLVM, both for
> > statically-compiled code and for JIT'd code, that depend on a
> > visibility boundary between certain core runtime services and the
> > user code being compiled to provide for effective optimization.
> 
> Don't a lot of people use not-shipped-with-libc malloc/free
> replacements? While LTO'ing your program with libc itself would seem
> unlikely, I don't think LTO'ing a program along with a malloc
> replacement is that unusual. (Either with a fully custom malloc or
> with something like tcmalloc).

Shipping with a custom malloc is common, I agree. I don't know that LTO'ing in the malloc implementation is particularly common. Either way, however, we don't support that in the optimizer. To support that, we need to turn off the aliasing assumptions we place on malloc's return values (and, if we add something along the lines of this thread, we need to turn that off too most likely).

 -Hal

> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory