Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: bad types originating from ssa rule to inline memmove #37381
generic.rules contains this rule:
The type of the moved object created here often doesn't match the size of the move.
For example, the most common case is copying a few bytes, so, for example,
This doesn't matter right now, because the backends don't pay any attention to the type of
The right type here is an array type, with elem
I'm not quite sure what we should do here. Maybe just remove the type Aux from Move?
The type Aux for Move is used for the write barrier pass to insert write barriers. But for types that don't contain pointers, it doesn't really matter -- the write barrier pass just needs to know it doesn't contain pointers. (For pointerful types, it does need to be correct.)
Also, on some architectures, the type's alignment is used in lowering.
So for the memmove case, it is fine to use byte type (for now), which is pointerless and has minimum alignment. Maybe leave a comment?
I couldn't quite convince myself that the current inline-memmove rule doesn't screw this up. I think it may be possible on amd64 to copy 2 pointers with this (say