Displaying 3 results from an estimated 3 matches for "2828bf59".
2013 Jan 14
4
[LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
...eadable structure is the first:
minsizeopt
sizeopt
quickopt
opt
maxopt
I'd like to hear some support for one or the other of these before deciding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/2828bf59/attachment.html>
2013 Jan 14
0
[LLVMdev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
If I understand the attributes correctly, they would be function-level
attributes applied to IR functions, correct? I'm curious what the
semantics would be for cross-function optimization. For example, consider
a function "foo" defined with maxopt and a function "bar" defined with
optsize. If foo() calls bar() and the inliner wants to inline bar() into
foo(), is that
2013 Jan 14
17
[LLVMdev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
This has been an idea floating around in my head for a while and after
several discussions with others it continues to hold up so I thought I
would mail it out. Sorry for cross posting to both lists, but this is an
issue that would significantly impact both LLVM and Clang.
Essentially, LLVM provides canned optimization "levels" for frontends to
re-use. This is nothing new. However, we