[Mesa-stable] [Mesa-dev] [PATCH] swr: fix -march flag for AVX

[Steven Newbury]

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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-stable/attachments/20160613/319aaa9a/attachment.sig>