Closed yuyang-ok closed 2 years ago
@yuyang-ok this is a bug in the metadata that your backend is providing to the register allocator, I think. Take a look at this line in the RA2 input dump:
inst7: op Def: v137i reg [p7i], Def: v134i reg [p29i], Use: v130i reg [p12i], Use: v138i reg [p7i], Use: v131i reg [p13i]
this is showing that RA2 believes that v137 is a def, and v138 is a use. Defs ordinarily happen at the "late" point of an instruction, and uses happen at the "early" point. So they can both be assigned the same register, because for a normal single instruction, writing results to registers happens after reads of inputs.
For pseudoinstructions that lower to multiple machine instructions and use temporaries internally, though, usually what you want is for the temp to not conflict with inputs or outputs. In this case you can define the temp as an "early def", which guarantees it will not be allocated into the same register as any input.
Similarly, if your machine sequence reads an input after it starts writing any outputs, you will want to define that input as a "late use".
The OperandCollector
trait provides a method to define early defs. You can see an example of its use for a temporary register here.
So this is not a bug in Cranelift or RA2, but the APIs are definitely subtle!
One final thing: please do not copy and paste the entire trace log into an issue, and please put a short summary of the problem before dumping a huge amount of detail. Doing these things makes it much, much easier to understand the issue and help you. I made the same request earlier in bytecodealliance/wasmtime#4110 and it really is important; thank you!
ok,I thought more information should helpful.
the alias v133 := v138 cause v133 def and not use ,liferange been shorted to it's def,I have v133,c137,v138 go to the same register "t2" .