Mark Mitchell wrote: >Paolo Carlini wrote: > >>Actually, the situation is not as bad, as far as I can see: the worst >>case is i386 vs i486+, and Old-Sparc vs New-Sparc. More generally, a >>targer either cannot implement the builtin at all (a trivial fall back >>using locks or no MT support at all) or can in no more than 1 >>non-trivial way. >> >> >Are you saying that you don't expect there to ever be an architecture >that might have three or more ways of doing locking? That seems rather >optimistic to me. I think we ought to plan for needing as many versions >as we have CPUs, roughly speaking. > > Yes, in principle you are right, but in that case we can reorder the ifs: first i686, last i386 ;) Seriously earlier today I was hoping we can have something smarter than a series of conditionals at the level of libgcc, I don't know it much. I was hoping we can manage to install a version of it "knowing the target", so to speak.
>As for the specific IA32 case, I think you're suggesting that we ought >to inline the sequence if (at least) -march=i486 is passed. If we >currently use the same sequences for all i486 and higher processors, >then that's a fine idea; there's not much point in making a library call >to a function that will just do that one sequence, with the only benefit >being that someone might later be able to replace that function if some >as-of-yet uknown IA32 processor needs a different sequence. > Yes. My point, more correctly, is that, when -march=i486+ is passed, *nothing* would change compared to what happens *now*. Again, I don't know the details of Richard's implementation but the real new things that we are discussing today kick-in when i386 (the default) is in effect. Paolo.
