[cfe-dev] [RFC] Changing/clarifying clang's handling of -fno-builtin and -ffreestanding

[Mehdi Amini via cfe-dev]

> On Jan 7, 2017, at 1:40 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> 
> On 01/07/2017 02:06 AM, Mehdi Amini via cfe-dev wrote:
>> Hi,
>> 
>> I’m trying to “fix” a longstanding issue about TLI options and LTO: we’re not preserving -ffreestanding of -veclib options from the compile phase to the link phase.
>> 
>> As a starting point, I need to clarify our handling of -ffreestanding and -fno-builtin. Right now clang does not differentiate between the two (except that -ffreestanding disable special handling of function “main”).
>> 
>> Here is the proposed behavior:
>> 
>> 1) -ffreestanding carries the fact that the compiler can’t assume anything about the environment: i.e. the libc is not present and the compiler should not create calls to libc functions. -ffreestanding implies -fno-builtin.
> 
> Even freestanding implementations are required to support certain functions (e.g. memcpy). -ffreestanding should only disable those not required.

Right there are a few exceptions.

> 
>>  2)  -fno-builtin describe the handling of the compiler with respect to the *source*. It tells the compiler to not assume anything about a call to, let say, malloc() in the source. We implement this already using the LLVM attribute “nobuiltin” on such calls. But I’d like to stop removing these builtins from the TLI and allow LLVM to create a call to (for example) memset() even with -fno-builtin.
> This makes sense to me.
>> 
>> LTO will happily implement freestanding and veclib through module flags, without having to care about the list of “no-builtin”, which will be carried by the function declaration  and the call sites attributes (we can discuss further the merging strategy in case of incoherency between modules, but I’d like to get us to agree on the high level bits first).
>> 
>> I’d be interested to know if this is in line with GCC handling of such options (I can’t be 100% sure just by reading the doc).
>> 
>> Note also that this is going quite against (some of) the previous views developed in this thread: http://lists.llvm.org/pipermail/llvm-dev/2013-February/059562.html
> 
> I skimmed the thread, but can you be more specific about to which views you're referring?

The thread had multiple views about what to support and how, but re-reading it I may have misunderstood (part of) it last night, it is not that different.

> The thread is also somewhat out of date because we do now implement -fno-builtin-FOO.

Well we don’t serialize the -fno-builtin-FOO to the IR, do we?

For instance the “devirtualization” case mentioned by Chris here: http://lists.llvm.org/pipermail/llvm-dev/2013-February/059621.html is not handled with LTO and  -fno-builtin-printf today, and it wouldn’t be handled by a non-LTO compilation with my plan.

— 
Mehdi