[llvm] r332452 - [SimplifyLibcalls] Replace locked IO with unlocked IO

[Friedman, Eli via llvm-commits]

On 5/31/2018 12:07 AM, Eric Christopher wrote:
> I'm currently not entirely sure we want to do this class of 
> optimizations for a few reasons:
>
> a) This ends up being an interesting educational problem on the 
> contents of a particular platform's libc - in particular, people that 
> write small libc interceptors are going to have to update just for 
> this in order to successfully build. I updated a few recently, but 
> this seems to be something that's going to be frustrating at llvm 
> release time. It will require anyone that's using a libc interceptor 
> to run into some odd problems if they don't -fno-builtin some new 
> functions or make sure that they add the unlocked versions which are 
> technically not required, but may exist on a system.

Yes, this is a concern.  But I'm not sure where exactly we would draw 
the line here; do we want to document some "minimal" set of C library 
functions that LLVM might call for each target, given input which 
doesn't explicitly call those functions?  Or are functions that do I/O 
special?  Or do we just want to use some informal "don't rock the boat 
unless we see improvements on SPEC" rule?  (We already do various 
similar transforms, like printf->puts, sin->sinf, automatic recognition 
of memset_pattern16, etc.)

> b) I believe I've found a bug in the current (theoretical) basis of 
> this which is: fopen could capture the file argument and do whatever 
> it wants with it. (and even after my fix, -fno-builtin-fopen still 
> didn't have individual -fno-builtin support which means you really 
> couldn't distinguish this at the time from clang - I've since fixed 
> this). This may not be the case anymore, but...

Assuming fopen returns a unique FILE* is just like assuming malloc 
returns a unique memory allocation; it's just assuming the C library 
works as documented.  This doesn't seem particularly controversial.

> What's the overall gain we're getting for doing this optimization? It 
> seems to be a lot of pain for not a lot of win in general 
> applications? Is there some benchmark here?

Dávid said he saw substantial gains on microbenchmarks... not sure what 
sort of general benchmarking was involved.  I'll let him comment on that 
more.

-Eli

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