On Tue, Mar 27, 2018 at 5:35 PM, Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 03/28/2018 01:43 AM, Michael Clark wrote:
> > > +if ((ct & TCG_CT_CONST_N12) && val >= -2047 && val <= 2047) {
> >
> > +2048?
>
Yes of course, you're right. It's safe. I just hadn't thought
On 03/28/2018 01:43 AM, Michael Clark wrote:
> > + if ((ct & TCG_CT_CONST_N12) && val >= -2047 && val <= 2047) {
>
> +2048?
>
> We use this constraint for a negatable immediate and the constraint is only
> applied to sub. We have no subi, so we implement subi as addi rd, rs1, -imm
>
>
On Tue, Mar 27, 2018 at 3:52 AM, Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 03/25/2018 05:24 AM, Michael Clark wrote:
> > Running with `-d in_asm,op,op_opt,out_asm` is very helpful
> > for debugging. Note: due to a limitation in QEMU, the backend
> > disassembler is not compiled
On 03/25/2018 05:24 AM, Michael Clark wrote:
> Running with `-d in_asm,op,op_opt,out_asm` is very helpful
> for debugging. Note: due to a limitation in QEMU, the backend
> disassembler is not compiled, unless the backend matches
> the front-end, so `scripts/disas-objdump.pl` is required
> to decode
On 03/27/2018 08:26 AM, Michael Clark wrote:
> IN:
> 0x00011138: 82b7 lui t0,-2147483648
> 0x0001113c: 8337 lui t1,-32768
> 0x00011140: 0262a433 mulhsu s0,t0,t1
> 0x00011144: 84b7 lu
What is quite fascinating is that it appears that TCG constant folding is
causing the mulhsu test to fail, not the TCG backend, which suggests either
a RISC-V front-end bug or a TCG middle-end bug. Anyway, it's odd.
Below are the mulhsu tests. Note TEST_RR_OP 7 is the test that is failing.
I thoug
This patch adds an experimental RISC-V TCG backend.
We have been dogfooding the RISC-V QEMU front-end with Fedora
to develop a RISC-V TCG backend. The RISC-V TCG backend can
be built inside of the QEMU RISC-V 'virt' machine using
the Fedora stage 4 disk image:
- https://fedoraproject.org/wiki/Arc
