Sorry something wrong with my sent email and my answer in the email was mixed with your text. Here are my response again:
First of all, porting GCC to one more target is not a simple task. In Cygnus (a company which made a lot of GCC ports), it usually took half a year for a developer with some experience to compile a "hello, world" program. Of course, there are people who could make a port much faster, e.g. Mike Meissner who made more than 10 ports. But probably for a novice like you, I'd plan on 6 months of full work at least. You will learn a lot about GCC during this work. To use GCC optimizations fully (e.g. generate madd insns by the GCC combiner pass), I believe you should get rid of stack insns: all operands should be explicit. And generation of stack insns should be the very last pass of GCC. You could adapt the reg-stack.cc pass for this or make your own machine-dependent pass (it is easier for implementation review and approval too). The machine-dependent pass can do some optimization too if it is necessary, e.g. renumbering local vars to make frequently used vars have smaller numbers (but I am not sure it will be necessary after IRA). Local variables should be pseudos starting with a very big number to avoid spilling. And hard registers (numbered before the first pseudo-register) should be final local variable numbers. I think FIRST_PSEUDO_REGISTER=10000 is enough to avoid spilling. The most demanding benchmarking program I know, fppp, has register pressure of several hundred only. You can divide 10000 hard registers by mode (integer, FP, vector hard regs). That is the high-level wasm port design I think is worth doing. I think although wasm is unusual, it is not complicated (real hardware targets are less regular than wasm). Probably RTL insns for wasm will have only one alternative, no secondary memory, no secondary reload, etc. When you run into a problem, look at how other ports solve the problem — the simpler and more regular the port, the better (I'd recommend a classic RISC architecture for this). Probably, you will need to switch off some code in LRA, e.g. inheritance (as you will have no spilling), hard reg splitting (because you always have enough regs), or maybe register elimination. Also, when working on RA for wasm, you could switch off other LRA optimizations and subpasses first (like rematerialization, equivalence substitution), and switch them on later (if they give some benefits). It may be that after switching off all LRA optimizations, LRA will only need to change pseudos to hard regs and check that the insn constraints are satisfied. You can switch off regional RA in IRA (I don't think it is necessary for wasm as it has an unconstrained number of locals, and regional RA can only help to generate smaller numbers for local vars in a region/loop). You could also start with IRA fast_allocation, which is much simpler than coloring, but I am not sure it saves you time.
