On Tue, 2005-11-22 at 01:53, Richard Guenther wrote: > Like f.i. as I proposed in > http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00965.html > maybe you could comment on that approach. Sofar the feedback was negative, > so I didn't yet work further on it.
I fell behind on gcc-patches reading a while ago. My employer has been keeping me busy with customer work, which is both good and bad. Your proposal is more what I was thinking. It isn't clear how this solves Piotr Wyderski's problem though. The main problem I see is that we don't have a good argument for adding it now. It is certainly something that would be nice to have, but we don't actually need it yet. You can make a more convincing argument if you have an optimizer pass that uses it. There is also an issue here of whether we should have builtin functions or a variable to check. The single variable solution may run into trouble later as 32-bits may not be enough for every feature we want to test. The extra overhead at startup may annoy some people that don't care about these features. Using separate builtin functions adds overhead though, as then we might end up executing multiple cpuid instructions, instead of just one in your approach. It isn't clear which is the best approach. If we had optimizer code relying on this stuff, this might help resolve the issue. By the way, there is already some related code in config/i386/crtfastmath.c. This probably should be updated as part of your patch. With your patch, compiling with -ffast-math, we would be executing two constructors at program startup, both of which are executing cpuid and parsing its result. There should be a better way to do this. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
