This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Function specific optimizations call for discussion


On Nov 29, 2007 2:27 AM, Michael Meissner <michael.meissner@amd.com> wrote:
> One of the things that I've been interested in is adding support to GCC to
> compile individual functions with specific target options.  I first presented a
> draft at the Google mini-summit, and then another draft at the GCC developer
> summit last July.
>
> In the x86 world this would mean saying that an individual function can use
> SSE5 instructions or SSE4.1 instructions.  This would simplify things for
> people who need to write high performance libraries that run on different
> architectures, and need to be optimal on each platform.  Ultimately, the goal
> is to allow hotspot functions to be compiled several times with different
> target specific optimizations.  I would welcome any thoughts or suggestions
> about this proposal.
>
> The proposal is at:
> http://gcc.gnu.org/wiki/FunctionSpecificOpt

Regarding the static constructors/destructors, we can version them as
well. In case a person wishes to annotate them, he can use:
__attribute__(sse4a) or change the constructor function name to
name__v__sse4a__ or so. He can safely assume that it won't execute if
the feature bit isn't present. We would simply ret if the feature bit
isn't supported. Multiple attributes are supported for any function,
and it shouldnt be a problem :-) This means the detection of features
would be done before the program's actual execution.

>
> Part of the infrastructure work for doing this is already addressed in function
> adaption project and we will work together with that team:
> http://gcc.gnu.org/wiki/functionAdaptation
>
> One of the things that I have considered and not added to the current proposal
> is to change most of the -f, -O, -W options for a function.  This would be
> relatively simple to add once the infrastructure is in place, but it can really
> complicate things, since various optimizations depend on other optimizations
> having been done.  Similarly, the -mtune= and -march= options can overly
> complicate matters.
>

As for setting -f, there are flags like: stack-protector-all which can
not be set at a function level. The problem happens when a flag is set
to 0/1 (not 2) and is valid for a whole compilation unit.. (It might
be there, I'm saying); We should clearly split the common.opt/annotate
it with the required information so we can determine which ones can
not be unset when set or vice-versa. The warn/optimization levels
would inherit/differenciate from the parent settings (compilation unit
or enclosing function).

> In addition, attribute(cold) and attribute(hot) will set the optimization level
> to -Os and -O3.
>

It might be possible that he wishes to optimize for size (not inline
function calls/unroll loops, for instance)  but he might want it
versioned; . Versioning will increase text size only if all versions
are loaded during runtime.

> I will be away on vacation from December 3-8th, and not reading mail during
> that time.
>
> --
> Michael Meissner, AMD
> 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
> michael.meissner@amd.com
>
>
>


-- 
Karthik


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]