llvm dev - May 2012 - [LLVMdev] [RFC] Encoding Compile Flags into the IR

On Apr 30, 2012, at 1:00 PM, dag at cray.com wrote:
> Bill Wendling <wendling at apple.com> writes:
> 
>> Link-Time Optimization has a problem. We need to preserve some of the
>> flags with which the modules were compiled so that the semantics of
>> the resulting program are correct. For example, a module compiled with
>> `-msoft-float' should use library calls for floating point. And
that's
>> only the tip of the proverbial iceberg.
> 
> This is an important missing feature.
> 
>> - Named metadata would be used for those options which affect code
>> generation for the functions, but which doesn't prevent two modules
>> from being merged together. For example, `-fomit-frame-pointer'
>> applies to individual functions, but it doesn't prevent a module
>> compiled with `-fno-omit-frame-pointer' from being merged with one
>> compiled with `-fomit-frame-pointer'. We would use a named metadata
>> flag:
> 
> Doesn't this violate the "no semantics" requirement of
metadata?  What
> happens if the metadata gets dropped?
> 
Named metadata cannot be stripped by normal methods.

-bw

On Apr 30, 2012, at 4:12 PM, Bill Wendling wrote:
> On Apr 30, 2012, at 1:00 PM, dag at cray.com wrote:
> 
>> Bill Wendling <wendling at apple.com> writes:
>> 
>>> Link-Time Optimization has a problem. We need to preserve some of
the
>>> flags with which the modules were compiled so that the semantics of
>>> the resulting program are correct. For example, a module compiled
with
>>> `-msoft-float' should use library calls for floating point. And
that's
>>> only the tip of the proverbial iceberg.
>> 
>> This is an important missing feature.
>> 
>>> - Named metadata would be used for those options which affect code
>>> generation for the functions, but which doesn't prevent two
modules
>>> from being merged together. For example, `-fomit-frame-pointer'
>>> applies to individual functions, but it doesn't prevent a
module
>>> compiled with `-fno-omit-frame-pointer' from being merged with
one
>>> compiled with `-fomit-frame-pointer'. We would use a named
metadata
>>> flag:
>> 
>> Doesn't this violate the "no semantics" requirement of
metadata?  What
>> happens if the metadata gets dropped?
>> 
> Named metadata cannot be stripped by normal methods.
> 
Do we elsewhere use named metadata for any information that is required for
correctness?
> -bw
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 1 May 2012 02:11, Jim Grosbach <grosbach at apple.com>
wrote:
>> Named metadata cannot be stripped by normal methods.
>
> Do we elsewhere use named metadata for any information that is required for
correctness?
AFAIK, only debug info uses it.

-- 
cheers,
--renato

http://systemcall.org/

On Apr 30, 2012, at 6:11 PM, Jim Grosbach wrote:
> On Apr 30, 2012, at 4:12 PM, Bill Wendling wrote:
>> On Apr 30, 2012, at 1:00 PM, dag at cray.com wrote:
>>> Bill Wendling <wendling at apple.com> writes:
>>> 
>>>> Link-Time Optimization has a problem. We need to preserve some
of the
>>>> flags with which the modules were compiled so that the
semantics of
>>>> the resulting program are correct. For example, a module
compiled with
>>>> `-msoft-float' should use library calls for floating point.
And that's
>>>> only the tip of the proverbial iceberg.
>>> 
>>> This is an important missing feature.
>>> 
>>>> - Named metadata would be used for those options which affect
code
>>>> generation for the functions, but which doesn't prevent two
modules
>>>> from being merged together. For example,
`-fomit-frame-pointer'
>>>> applies to individual functions, but it doesn't prevent a
module
>>>> compiled with `-fno-omit-frame-pointer' from being merged
with one
>>>> compiled with `-fomit-frame-pointer'. We would use a named
metadata
>>>> flag:
>>> 
>>> Doesn't this violate the "no semantics" requirement
of metadata?  What
>>> happens if the metadata gets dropped?
>>> 
>> Named metadata cannot be stripped by normal methods.
>> 
> 
> Do we elsewhere use named metadata for any information that is required for
correctness?
IIRC, the ARC frontend uses it to tell the optimizer what assembly
(if any) to add after calls to objc_retainAutoreleasedReturnValue.

John.

On Apr 30, 2012, at 6:11 PM, Jim Grosbach wrote:
> On Apr 30, 2012, at 4:12 PM, Bill Wendling wrote:
> 
>> On Apr 30, 2012, at 1:00 PM, dag at cray.com wrote:
>> 
>>> Bill Wendling <wendling at apple.com> writes:
>>> 
>>>> Link-Time Optimization has a problem. We need to preserve some
of the
>>>> flags with which the modules were compiled so that the
semantics of
>>>> the resulting program are correct. For example, a module
compiled with
>>>> `-msoft-float' should use library calls for floating point.
And that's
>>>> only the tip of the proverbial iceberg.
>>> 
>>> This is an important missing feature.
>>> 
>>>> - Named metadata would be used for those options which affect
code
>>>> generation for the functions, but which doesn't prevent two
modules
>>>> from being merged together. For example,
`-fomit-frame-pointer'
>>>> applies to individual functions, but it doesn't prevent a
module
>>>> compiled with `-fno-omit-frame-pointer' from being merged
with one
>>>> compiled with `-fomit-frame-pointer'. We would use a named
metadata
>>>> flag:
>>> 
>>> Doesn't this violate the "no semantics" requirement
of metadata?  What
>>> happens if the metadata gets dropped?
>>> 
>> Named metadata cannot be stripped by normal methods.
>> 
> 
> Do we elsewhere use named metadata for any information that is required for
correctness?
> 
The "Module-level Flags" is implemented using named metadata. Removing
those flags would result in incorrect semantics for the Objective-C runtime. So
there is a precedent.

-bw