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

[Mehdi Amini via cfe-dev]

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. 
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.

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

Best,

— 
Mehdi