@jserv I understand that we can add a m option to determine whether shecc generates hardware integer multiplication and division instructions.

However, I consider shecc can still generate multiplication instructions for ARM even if the m option is closed. Because ARMv7-A inherently includes multiplication instruction, we can generate it directly without any concern.

Therefore, for the implementation of the m option, I think that I can just handle whether the hardware integer division instructions are generated for ARM.

However, I consider shecc can still generate multiplication instructions for ARM even if the m option is closed. Because ARMv7-A inherently includes multiplication instruction, we can generate it directly without any concern.
Therefore, for the implementation of the m option, I think that I can just handle whether the hardware integer division instructions are generated for ARM.

Yes for Arm backend. Please proceed.

The reference implementation mentioned in #46 assumes that the dividend and divisor are unsigned integers, but it may fail if at least one of them is a signed integer.

Can I suppose that shecc will not encounter any signed integer division and just handle unsigned integer division?
Or do we must let shecc handle both of them?

Can I suppose that shecc will not encounter any signed integer division and just handle unsigned integer division? Or do we must let shecc handle both of them?

Given your aim to replace the current udiv/sdiv instruction, the proposed changes should also ensure division is covered for both signed and unsigned integers, mirroring the approach gcc took with its libgcc.

By the way, I enjoy this article Fast(est) Double-Word Integer Division.

I have a new question about the right shift operation. During these days, I test the following code:

/* test.c */
int main() {
    printf("%d\n", -2 >> 31);
    return 0;
}

In C99, It mentions that it is an implementation-defined behavior for using right shift operation on signed integers.

If we use gcc and clang to compile and execute it, we can all obtain the output -1:

$ gcc -o test test.c
$ ./test
-1
$ clang -o test test.c
$ ./test
-1

I believe it may be a convention that many compilers use arithmetic right shift instructions for signed integers.

But, when using shecc to test the right shift operation, we will get the output 1 because shecc uses logical right shift instructions for signed integers:

$ qemu-arm out/shecc-stage2.elf -o test test.c
$ qemu-arm test
1

Should we instruct shecc to generate arithmetic right shift instructions as well?

In C99, It mentions that it is an implementation-defined behavior for using right shift operation on signed integers.
[...]
Should we instruct shecc to generate arithmetic right shift instructions as well?

@vacantron, can you comment this?

In C99, It mentions that it is an implementation-defined behavior for using right shift operation on signed integers.
[...]
Should we instruct shecc to generate arithmetic right shift instructions as well?

Yes, the behavior should be consistent with GCC or Clang.

Thank you for the report!

I defer to @vacantron for his performance evaluation.

I encounter a new issue when rebasing:

$ make
  CC    out/src/main.o
  LD    out/shecc
  SHECC out/shecc-stage1.elf
munmap_chunk(): invalid pointer
Aborted (core dumped)
make: *** [Makefile:80: out/shecc-stage1.elf] Error 134

Then, I checked the source code including my changes, and found that shecc has a potential problem:

$ wc --bytes src/* out/libc.inc
  8120 src/arm.c
 15909 src/arm-codegen.c
 15909 src/codegen.c
  8889 src/defs.h
  8052 src/elf.c
 22550 src/globals.c
 16317 src/lexer.c
  2526 src/main.c
 94104 src/parser.c
  1716 src/peephole.c
 25695 src/reg-alloc.c
  8952 src/riscv.c
 11660 src/riscv-codegen.c
 38460 src/ssa.c
 25330 out/libc.inc
304189 total

It can be observed that the total bytes of all source files have exceeded 278528, as defined by MAX_SOURCE.
Even after reducing the source about RISC-V or Arm, the total bytes of the utilized source files still approximate 280000.

This will cause the SOURCE variable not to store all bytes of the sources and the executable may access invalid memory regions.

Should I enlarge the allocated size in this PR to prevent the potential problem?

Should I enlarge the allocated size in this PR to prevent the potential problem?

Yes, please do so.

I defer to @vacantron for his performance evaluation.

Because of #120 , the measurement of the performance is postponed. I prefer to apply this patch first.

Thank @DrXiao for contributing!

@jserv May I ask why this PR can be merged? Or will this PR be reopened and requested to be improved again in the future?

May I ask why this PR can be merged? Or will this PR be reopened and requested to be improved again in the future?

The latter.