[llvm-dev] RFC: Adding argument allocas

[Friedman, Eli via llvm-dev]

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.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project