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

Tue Jan 10 05:43:03 PST 2017

I think that whether the implementation is freestanding versus hosted is independent of whether or not the libraries are available and hence, whether the builtins can be used or not.

I don't have a copy of C11, but C90 and C99 both permit a conforming freestanding implementation to provide the ISO C libraries, it does not mandate that they must NOT be present.  These Standards also state that a conforming freestanding application cannot assume that the Standard libraries are present.

This means that the statement:

   1) -ffreestanding carries the fact that the compiler can’t assume anything about the environment

is not really true, since the compiler plus its libraries "is" the implementation and can assume whatever is has implemented.  However, a program written by the user and built with this implementation may not assume the existence of the libraries if it intends to claim to be a conforming freestanding application.

This means that a given implementation should be perfectly free to provide or not provide the libraries (or subsets of the libraries), and that the compiler should be free to use them even if the conforming freestanding application does not refer to them.

Would it not be better to allow the target to decide whether the builtins should be used or not?  Simply implying no builtins loses a lot of significant optimisation opportunities that are very valuable to embedded freestanding applications.

As it happens, our implementation is freestanding because we have no operating system, but we still provide the almost the entire ISO C libraries, although some routines will return an error (e.g. 'fopen' will return a valid ISO C failure [in 'errno'] saying that it was unable to open the file - we have no file-system).

We do suppress some builtins that we have decided not to support be automatically adding '-fno-builtin-XXX' in our implementation of 'void Clang::AddShaveTargetArgs(const ArgList &args, ArgStringList &cmdArgs) const'.

As an aside, we also support initialisation, finalisation and normal 'main' even though the platform has no OS.

So I don't think that '-ffreestanding' should imply '-fno-builtin' automatically.

	MartinO

-----Original Message-----
From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via cfe-dev
Sent: 08 January 2017 21:07
To: Mehdi Amini <mehdi.amini at apple.com>
Cc: Clang Dev <cfe-dev at lists.llvm.org>; joerg at NetBSD.org
Subject: Re: [cfe-dev] [RFC] Changing/clarifying clang's handling of -fno-builtin and -ffreestanding

On 01/07/2017 04:39 PM, Mehdi Amini wrote:
>> 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?

AFAIK, no.

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

This seems somewhat orthogonal, except for the fact that the changes you're proposing will regress anyone depending on this in non-LTO compilation, but we should fix this also.

  -Hal

>
> —
> Mehdi
>

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

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev