On Mon, 2016-06-13 at 09:03 -0400, Chuck Atkins wrote: > > Maybe I'm the only one who finds it horrible to override -march > > from > > within project build systems. It causes no end of problems with > > LTO, > > and results in objects being built inappropriately for the target > > as > > specified by the builder. > In general I would agree, yes, but I think swr is a somewhat unique > situation. The march flags don't apply to the entire build but only > to libswr. It's built as two separate libraries, one with AVX and > the other with AVX2, which the swr driver determines at runtime which > to load. As odd as it may seem to do so, it makes sense for the > current primary use case for swr which is in HPC environments where > the front end and service nodes are often a different (older usually) > architecture than the actual back end compute nodes. This lets you > build a Mesa that can target both optimally in a single build. > > I'm not necessarily arguing that it's the optimal way to achieve this > (it may be, I'm not sure), but it's certainly a reasonable approach. > Okay, fair enough, it could well be the exception to the rule. I've just been seeing a lot of projects either assuming instruction set extensions are always available at build time, which they may not being depending upon how the compiler was built, and/or specifying "-march" either overriding or clashing with the user specified build flags rather than accepting the user flags and aborting build or dropping inappropriate specialised functions/objects.
I've been trying to provide patches upstream in various projects (ostensibly to help support LTO more universally) but there's often more resistance than appreciation!
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
