Bug: http://b/327307773
Newer clang rejects this flag as unsupported. It is not necessary while linking because the flag is passed as an IR feature.
Change-Id: I781afd913be7c07612196e736c3ae58773791071
We fixed the clang driver to "do the right thing" based on target api level years ago, but these manual workarounds predate that (or were copy & pasted from places that predated that). We don't need them any more.
See https://github.com/android/ndk/issues/2005 for more detail.
Change-Id: I995741b8606e389e8de8272f1cc532624516245a
Latest compiler has merged both unaligned access flags into one.
TODO: This is needed until we change clang driver to enable -munaligned access by default.for Android b/327307773
Bug: 326790418
Change-Id: Ia8c29dc56104d2cffb8ac41aae6eeacccae68e61
The previous patch was insufficient. Craig Topper explains:
-fno-vectorize only disables the loop vectorizer
-fno-slp-vectorize only disables the SLP vectorizer
The backend can also use vector instructions for memcpy/memset or
combining multiple scalar loads and/or stores. That is independent
of -fno-vectorize.
-mllvm -vector-bits-min=0 will disable any use of fixed vectors. And
will make attribute(vector_size) get scalarized.
-mno-implicit-float will disable both vectorizers and
prevent the backend for using vectors for memcpy/memset
oor multiple scalar loads/stores. It will not affect
attribute(vector_size). -mno-implicit-float also prevents scalar
floating point instructions from being used for anything that didn’t
use float/double/_Float16/etc. type in source, but I don’t think that
happens on RISC-V today. 32-bit X86 can use a 64-bit x87 FP load as an
atomic load for uint64_t, for example. Basically -mno-implicit-float
is supposed to prevent the compiler from using FP or vectors when the
source doesn’t explicitly use FP or vectors.
So -mno-implicit-float was what we were actually looking for here. I've
done a clean build with this change, and see only the expected
(hand-written assembler) vector code in bionic, and the ART
ClassLinker::LoadClass() issue is gone too. As far as I can tell, the
remaining vector code is all deliberate in that sense.
We may still end up back here again, to change "gcv" to "gc", but that
still requires some code changes just to build, and still makes it less
obvious that this is just a temporary workaround for a qemu bug
(specifically https://gitlab.com/qemu-project/qemu/-/issues/1976).
Bug: http://b/320416684
Test: objdump
Change-Id: Ibd104e4289d6d1aaf441efa0440fedc90e3da29a
Until https://gitlab.com/qemu-project/qemu/-/issues/1976 is fixed, this
is just causing too much confusion and wasted time.
Removing V from the architecture string has the same effect, but
requires some code changes (to be able to compile code that's
_explicitly_ using V), and makes it less obvious that this is just a
temporary workaround for a qemu bug.
Bug: http://b/320416684
Test: objdump
Change-Id: Iec7d63ab227b31f82f530dabbdc4f3aa54277f04
By default clang assumes that on riscv64 jumps are really expensive.
That's probably not true for the kind of SoCs we're dealing with, but
more importantly (see the bug) it causes clang to do loads from the
right hand side of a `&&` before the left hand side has been evaluated.
This found one latent bug in libcore, and it doesn't seem like the best
use of anyone's time to have to chase similar issues if they're going
to be similarly latent for riscv64 when we get clang's default fixed.
Bug: https://github.com/google/android-riscv64/issues/124
Test: treehugger
Change-Id: I640f1b43ea3d2452366ab86e97a9189fa9f5326c
This reverts commit bce5507c02.
The update of LLVM to clang-r498229 resolved the error with sext.w as
resolved in D143594.
Bug: 275574215
Test: Verified boot of riscv64 phone target.
Change-Id: Ie31b7db03004c5aafb6067713ef5f819e0706b64
Cuttlefish still boots to homescreen, all instructions in the extension
are actually seen to be in use, and the bionic tests still pass.
Test: see above
Change-Id: I429729a722cdd7b3bdf257cb7329ee151ec998a0
Cuttlefish still boots to homescreen, all instructions in the extension
are actually seen to be in use, and the bionic tests still pass.
Test: see above
Change-Id: I6373fa6245115b9b6c845db03ee73b321c07e02a
We're switching from x18 to gp, in stages. This change frees up x18
again now bionic and ART have switched to gp. There's no need for a
corresponding "reserve gp" change because gp is automatically reserved.
That's what makes it the perfect choice for shadow call stack (at
least until we get Zsslpcfi and an actual hardware shadow stack pointer
special-purpose register).
Bug: https://github.com/google/android-riscv64/issues/72
Bug: http://b/277909695
Test: treehugger
Change-Id: Iaee1d44cba8daf5d4a27a3791fe3cc28ed1a5d9a
This reverts commit 9838acffdd.
Reason for revert: b/274947458
Broke CI.
Will reland with QEMU options once the host image is fixed.
Change-Id: I6ad847cde2a291b3dd5b92314b2011744de50883
This causes us to align the text section to 4KiB, not just the data
section. From the bug that added this for arm64, there was an admission
that it costs 17MiB across the tree, and a not entirely convincing claim
of a performance improvement (undermined by the fact that "some stuff
was faster, some stuff was slower"). See http://b/150506341 for that.
Anyway, let's assume we don't want this for riscv64 for now.
Test: `mm -j` in bionic and readelf on the resulting libtest_empty.so
Change-Id: I0ed592a97ef705175191d9c66271a599af4eb18f
Building for riscv64 fails with link errors on __thread variables.
Set -fno-emulated-tls to fix it.
Bug: 254713216
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true ndk_sysroot
Change-Id: I3dca81dfd277d681b6c868a5e8385e3a37335a5f
Add barebones riscv64-linux-android support. This should be enough
to add riscv64-specific entries to Android.bp files, but can't
actually compile anything until there are riscv64 toolchains.
Test: arch_test.go
Change-Id: I0dcc7e797d9352dd38243be908a7f19004ff3db1
