On 2007/11/29, Sylvain Pion <[EMAIL PROTECTED]> > Michael Meissner a écrit : > > 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. > > > I'm wondering if this proposal would support specifying things > like adding -frounding-math when compiling specific functions. > ( This particular case is connected to pragma FENV_ACCESS though. ) > > > Also, would this work when the functions is inline? > I mean the case when the caller does not have the same attribute, > but the inlined code of the callee still respects the attribute > set for the inlined callee.
Autovectorization is still a researching issue. The generated program/library should depend of the capabilities of present historical machines from no-SIMD instructions until the last SSE9 instructions set (SSE, SSE2, SSE3, SSE4, SSE4.1, SSE5, 3DNow!, 3DNow+!...) But there are many distros LiveCDs/LiveDVDs that they don't want to grow brutally their sizes (e.g. one specific LiveCD for supporting each one i-arch that has SSEi, i=1..9). The good solution is extending the ELF format to insert SIMD stubs to unique portable program/library for historical machines, and the loader will do the work of choosing the adequate stub for the correspondent old or new machine. But there is another problem, this strategy doesn't works fully in clusters with processes's migration (ala old OpenMosix) because OpenMosix only migrates processes with identical instructions sets to use for all machines. J.C.Pizarro
