Add -flto flags in WSClean AMD

[AlexKurek]

Description

-lfto was missing. It is here in Intel recipe.

[tikk3r]

Those were not supposed to be there in the Intel recipe. I missed those when looking at the PR. Please make sure changes to compiler flags sneak in with unrelated PRs. I think link time optimisation should be relatively harmless, but this is something that I think should be kept individual track of with some benchmarks ideally.

[AlexKurek]

In fact, maybe it would be even better to do this benchamrks passing the flag globally, not just to WSClean?

[AlexKurek]

Using current master where:

HAS_CUDA=false
HAS_MKL=false
MARCH=cascadelake
MTUNE=cascadelake
NOAVX512=false
DEBUG=false
OPENBLASTARGET=SKYLAKEX

and https://github.com/tikk3r/flocs/blob/fedora-py3/benches/benchmark_image_6asec.sh as a test, but smaller size and niter, and passing LTO flags globally:

export CFLAGS="-w -march=${MARCH} -mtune=${MTUNE} -flto"
export CXXFLAGS="-w -march=${MARCH} -mtune=${MTUNE} -std=${CPPSTD} -flto"

I got:

no LTO
17m14,381s

LTO
17m7,313s

at the expanse of much longer compilation time.
I would not cross out LTO just yet:

• It works better in the case of Numpy and Scipy (Use MKL in NumPy and SciPy #222)
• still even here other components (DDF, DP3) may be faster
• I had to disable MKL (Intel crashes at WSClean build if MKL = true #253)
• there are some good opinions on the Internet

But since it does not work for WSClean, maybe we should close it?

[tikk3r]

Good to see that it doesn't see to have a negative impact at least. I'm not crossing LTO out, but I do want to confirm via benchmarks that it doesn't harm performance and is worth it. With a marginal 0.5% improvement while taking much longer to build. I would put that in the "not worth it" territory.

Closing this, because unfortunately it doesn't seem to have a worthwhile benefit.