There was one change required here: support for "MEMMODEL_SYNC_*". This
very long GCC post <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697>
talks about the formalization of the C++ memory model. It looks like
this is it to allow for some ARM stupidity where they can speculatively
issue some memory operations.
As far as I can tell, the right thing to do here is to just treat the
SYNC versions the same as the non-SYNC versions -- this is the same
thing ia64 and rs600 do. I can't find "MEMMODEL_SYNC" anywhere else
interesting, so there might be some flag to set to avoid doing this, but
I couldn't find it.
LRA is the new register allocator, replacing the complicated reload pass.
It's a much better design, and it seems likely that it will ultimately
replace reload altogether. Rather than contending with the vagaries of
both schemes, I think we should abandon reload altogether.
For RISC-V, LRA seems to have a mixed performance impact, but it will
get better over time.
We have no pattern for moving between a double-precision floating-point
register and an integer register in RV32. This makes the compiler choke.
This workaround raises the cost of those moves significantly. This has
no effect on -O0, which always worked; the other -Ox all seem to work
now. For obvious reasons, this makes me very uncomfortable. But,
as far as I can tell, MIPS is relying on the same behavior.
If this bug rears its head again, no big deal: we can add an "instruction"
for this, which does something like
addi sp, sp, -16
fsd f4, 0(sp)
lw x6, 0(sp)
lw x7, 4(sp)
addi sp, sp, 16
This is heinous, but it's always correct. If the cost model is right,
the compiler will only very rarely invoke it, so the performance cost
of this ingorious hack will be hidden. @palmer-dabbelt
ADDR in this format is only meant to be a symbolic address, not a numeric
address. Things are this way because of linker relaxation. Passing a numeric
address would result in an internal assertion triggering, this patch just makes
gas reject these instructions cleanly.
This compiles glibc on a5 for me. This should fix bug #106.
This just requires a single extra argument to a function call, which I copied
from aarch64. I've only tested that newlib builds, but I don't see how this
could cause any problems... :)
I was hoping this would help with my attempts to integrate the GDB and binutils
ports into one repo for upstreaming, but it looks like 2.25.1 is still a bit
too old for this.
We'd changed the ISA string parser to be case-insensitive, but when doing that
it made all "X*" extensions upper case. The result was that the instruction
table matcher would skip "Xcustom" extensions, since they showed up as
"XCUSTOM".
This patch changes the ISA subset matching function to be case insensitive, to
match the parser.
This reverts commit e05cc858aa.
Too much code assumes LA maps to AUIPC. Perhaps that is unreasonable,
but the improvement of this patch is so minor that it seems hard to
justify going back and fixing the code.
Section merging could make a gp-relative reference go out of range
after relaxation. Stop relaxing LUIs against mergeable symbols, and
add error checking to catch things like this in the future.
I'm trying to rebase our binutils port off of upstream's git repo, and
this is one of the things I ended up noticing. I believe this is the
correct thing to do, since we're now only supporting riscv32/riscv64
as our tuples.
Andrew Waterman
Palmer Dabbelt
Palmer Dabbelt
Andrew Waterman
Joel Vandergriendt
SeungRyeol Lee
Yunsup Lee
T.J. Yang