[llvm-dev] RFC: Adding argument allocas

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Eli via llvm-dev Friedman" <llvm-dev at lists.llvm.org>
> To: "Reid Kleckner" <rnk at google.com>, "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Thursday, December 8, 2016 7:47:28 PM
> Subject: Re: [llvm-dev] RFC: Adding argument allocas
> 
> On 12/8/2016 5:05 PM, Reid Kleckner via llvm-dev wrote:
> > If the semantics are the same, it begs the question, why don’t we
> > pattern match the alloca and store to elide dead stores and reuse
> > existing argument stack slots? My main preference for adding a new
> > way
> > to do this is that it gives us simpler and smaller code in debug
> > builds, where we presumably don’t want to do this kind of pattern
> > recognition. My experience with our -O0 codegen is that we do a lot
> > of
> > useless copies to initialize parameters, and this leads to larger
> > output size, which slows things down. Having a more easily
> > recognizable idiom for getting the storage behind parameters if it
> > exists feels like a win.
> 
> Why don't we want to do this kind of pattern recognition at -O0?  We
> can
> do a fast scan which just looks at the entry block if you're
> concerned
> about compile-time.
> 
> > One other questionable side benefit of doing this is that it would
> > make it possible to implement va_start by taking the address of a
> > parameter and doing pointer arithmetic. While that code is fairly
> > invalid, it’s exactly what the MSVC STL headers do for 32-bit x86.
> > If
> > we make this work in Clang, we can remove our stdarg.h and vadefs.h
> > wrapper headers. Users often pass flags that cause clang to skip
> > these
> > wrapper headers, and then they file bugs complaining that va lists
> > don't work.
> 
> This ignores the other reason why this doesn't work at the moment:
> reading off the end of an alloca returns undef, whether or not the
> actual pointer value points at the data you want.  I mean, it's not
> impossible to make it work, but it involves a bunch of unrelated
> changes
> which I don't think we want to pursue.

I agree. Making reading past the end of an alloca defined behavior seems undesirable.

 -Hal

> 
> -Eli
> 
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory