Using the least common denominator is another food reason to consider link time optimization... I wonder if e.g. fatelf would make it easier to implement that. Multiple arm binaries glued together based on variant and hwcaps (e.g. v6+vfp-d16, v7+vfp-d32, v7+neon)? Heck, if fatelf were used, only one stage3 tar ball would be necessary for all arch's combined... although downloading would be significantly slower :-/
© Sent from my Android On May 18, 2012 1:10 AM, "Mike Frysinger" <[email protected]> wrote: > currently, we have the system: > - if chost matches *-softfloat-*, you get softfloat > - if chost matches *-hardfloat-*, you get hardfloat > - for everything else, you get the gcc default > > with the standardization work going on with armv7+ and hardfp, i've made > the > following change: > - if chost matches armv7*-softfloat-*, you got softfloat > - for all other armv7* targets, you get hardfloat vfp3-d16 > > along those lines, i've also slipped in: > - if chost matches armv6*-softfloat-*, you got softfloat > - for all other armv6* targets, you get hardfloat vfp > > considering vfp is required baseline in these cores now, it doesn't make > sense > to not use it if the user has explicitly stated they're targeting these > arches. > > if you really want to use a different default, you can still use > EXTRA_ECONF to > set whatever you want. > -mike >
