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/
John McCall
2012-May-01 07:38 UTC
[LLVMdev] [cfe-dev] [RFC] Encoding Compile Flags into the IR
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
Maybe Matching Threads
- [LLVMdev] [RFC] Encoding Compile Flags into the IR
- [LLVMdev] [RFC] Encoding Compile Flags into the IR
- [LLVMdev] [RFC] Encoding Compile Flags into the IR
- [LLVMdev] [cfe-dev] [RFC] Encoding Compile Flags into the IR
- [LLVMdev] [RFC] Encoding Compile Flags into the IR