On Thu, Mar 19, 2009 at 2:32 PM, Jason Moxham <ja...@njkfrudils.plus.com> wrote: > > On Thursday 19 March 2009 14:31:55 Gonzalo Tornaria wrote: >> On Wed, Mar 18, 2009 at 10:44 PM, Bill Hart <goodwillh...@googlemail.com> > wrote: >> > Wait, how does it currently decide which ABI to use? Does configure >> > decide that aside from what config.guess says. >> >> Yes, except config.guess may change it (but it shouldn't, as we >> discussed before this causes compilation failure, e.g. in a kvm >> virtual cpu which reports wrong cpuid). > > At the moment a kvm cpuid would be unrecognized , and so would default to > x86_64 the base architecture . If the kvm doesn't virtualize cpu then a > better choice may be K8 or core2 depending on the host cpu, do we know what > it does and whether is may return some info we can use to choose a better > path.
We know what KVM claims by default: family=6, model=2, stepping=3. Both for Intel or AMD (and the Vendor string is set accordingly). I believe neither vendor has a chip with this model. It's ok to choose any random default for such a KVM machine --- it means the compilation won't fail (this is very important for sage, where this is part of compilation of a large number of packages). If the user knows better, it is possible to configure kvm on the command line so that it claims a different family/model. It may be sensible to actually detect KVM with f=6, m=2, and give back a warning explaining to the user how to change this, but not fail. As it works now, for intel processors, all of them running in 64 bit will work (keep ABI=64) -- it was broken before. But for AMD, I think it is still broken, i.e. a KVM cpu in 64 bit mode will return "athlon", which in turn will force ABI=32, which in turn will make the compile to fail. >> Anyway, the point was, using the same name as gcc to avoid a mapping >> from cpu naming to gcc tuning options, but this is just another >> mapping which can be written, as long as the cpu names are >> fine-grained enough to get advantage of gcc tuning. >> > > You still have to write the same mapping regardless of weather the names match > or not , so we can call them what we want(nearly) Yes, definitely. We were lazy or ignorant at that moment to write a mapping, so we used identity... :-) >> e.g. calling "core2" a pentium D is not good, because -mtune=nocona >> gives better results than -mtune=core2 as shown by the benchmarks I >> posted in a different thread. Gonzalo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
