lld ignores it for shared libraries, but wild linker adds an .interp
section because of it. Regardless, llvm has long known to set the
correct linker flag when building for android.
Bug: 40208899
Change-Id: I50dc015946382f9e99289333e7d8b870409ed8d6
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/7874019
Reviewed-by: Frank Barchard <fbarchard@google.com>
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@chromium.org>
This reverts commit 6ecfe106c304d1eeaa31d1b29a42c58fb70d35ca.
This "explicit control" with -mlasx as the default is really surprising
and unfriendly to distro maintainers and/or downstream projects. They
already know using -m{no-,}l{a,}sx in CXXFLAGS to enable/disable the
LoongArch vector extensions, but this control does not respect those
flags already in the environment, forcing every distro and every
downstream project to wire an extra logic into their build system if
they need to change the default.
To make things worse, LSX is guaranteed to be available for LoongArch
desktop processors but LASX is not. Thus most downstream works will
indeed need to change the default for hardware compatibility.
"LASX is widely supported among LoongArch desktops and servers, and
performance is better than with LSX alone" is true, but in the future we
can make the use of LASX correctly guarded by runtime CPU feature check
to take the advantange without breaking the hardware compatibility.
No-Try: true
Change-Id: I43b31a139b106b7f6f8b6ca5dc04045633ea1989
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/6772565
Reviewed-by: Wan-Teh Chang <wtc@google.com>
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
And enable LASX by default for LoongArch builds, because LASX is
widely supported among LoongArch desktops and servers, and performance
is better than with LSX alone.
Because the LoongArch SIMD code is written to only compile if the
respective codegen option is enabled, but the defaults and availability
differ between compiler versions and target `-march` setting, the
codegen flags are explicitly added to CFLAGS for wider compatibility.
Bug: None
Change-Id: I735ceac0f6b46eea2155e58ecf3630383ef5b728
Reviewed-on: https://chromium-review.googlesource.com/c/libyuv/libyuv/+/6241804
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@chromium.org>
Also remove --if-needed from clang update in DEPS.
Bug: libyuv:816, libyuv:814
Test: bots still build and local GN build works
Change-Id: I91998b8eee1b0cbe344f02a9369a1bbc45cb0140
Reviewed-on: https://chromium-review.googlesource.com/1204790
Reviewed-by: Nico Weber <thakis@chromium.org>
Currently, libyuv supports MIPS SIMD Arch(MSA),
but libyuv does not supports MultiMedia Instruction(MMI)(such as loongson3a platform).
In order to improve performance of libyuv on loongson3a platform,
this provides optimize 98 functions with mmi.
BUG=libyuv:804
Change-Id: I8947626009efad769b3103a867363ece25d79629
Reviewed-on: https://chromium-review.googlesource.com/1122064
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
Reviewed-by: Frank Barchard <fbarchard@chromium.org>
Bug: libyuv:765
Test: build for mips still passes
Change-Id: I99105ad3951d2210c0793e3b9241c178442fdc37
Reviewed-on: https://chromium-review.googlesource.com/826404
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Commit-Queue: Frank Barchard <fbarchard@chromium.org>
follow up warning fixs
cpu_id.cc(167): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
lint warning: cpu_id.cc:171: Missing space before ( in if( [whitespace/parens] [5]
TBR=manojkumar.bhosale@imgtec.com
BUG=libyuv:634
TEST=try bots for windows.
Review URL: https://codereview.chromium.org/2365813002 .
As per the preparation patch added in Chromium sources at,
2150943003: Add MIPS SIMD Arch (MSA) build flags for GYP/GN builds
This patch adds first MSA optimized function in libYUV project.
BUG=libyuv:634
R=fbarchard@google.com
Review URL: https://codereview.chromium.org/2285683002 .
normally this warning is disabled but for nacl builds that
use clang its not. this CL makes the option universally disabled
for all clang based builds.
BUG=libyuv:581
TESTED=native_client/build/gyp_nacl all.gyp -Dgtest_target_type=executable -Dmsan=0 & ninja -C out/Debug libyuv
R=kjellander@chromium.org
Review URL: https://codereview.chromium.org/1865183002 .
previously the neon source code was broken into a separate
library built with -mfpu=neon for the neon assembly, while
the C code was built without neon.
In this change, the neon code is added to the main library
and all code built with neon.
TBR=harryjin@google.com
BUG=libyuv:371
Review URL: https://codereview.chromium.org/1392043003 .
In init functions, whether the code of NEON initialization is compiled
is decided by macros HAS_XXXX_NEON. These macros HAS_XXXX_NEON are defined
according to __ARM_NEON__/LIBYUV_NEON/__aarch64__. For ARM32, "-mfpu=neon"
isn't passed to the files containing init functions. So __ARM_NEON__ is
undefined which leads to NEON functions are disabled.
In this patch, LIBYUV_NEON is added to enable HAS_XXXX_NEON definition for ARM32.
BUG=none
TESTED=libyuv_unittest on android of ARM32/ARM64
R=fbarchard@google.com
Change-Id: Ib4201e7152d2aeb0ba80d18bbbd0487151e4564e
Review URL: https://webrtc-codereview.appspot.com/32959004
git-svn-id: http://libyuv.googlecode.com/svn/trunk@1277 16f28f9a-4ce2-e073-06de-1de4eb20be90
