Our processor only does 32bit reads and writes to memory. Changing a byte requires a 32bit read, modify, 32bit write sequence to change the 8bit value in memory.
How should this be handled?
Do any of the other current backends do this?
Hi,
Our processor only does 32bit reads and writes to memory. Changing a
byte requires a 32bit read, modify, 32bit write sequence to change the
8bit value in memory.How should this be handled?
your backend will have i32 as a legal type and i8 as an illegal type.
A store to an i8 will be automatically transformed into a "truncating"
to i8 store of i32. Such a truncating store means: the lower 8 bits
of this i32 value needs to be stored. When your backend sees such a
truncating store of an i32 V it will need to turn that into: read the
existing i32 value (W), replace the low 8 bits of W with the low 8
bits of V (high 8 bits on a big-endian machine), and write the new
W back.
Do any of the other current backends do this?
I don't know.
Ciao,
Duncan.
Duncan Sands wrote:
Hi,
Our processor only does 32bit reads and writes to memory. Changing a byte requires a 32bit read, modify, 32bit write sequence to change the 8bit value in memory.
How should this be handled?
your backend will have i32 as a legal type and i8 as an illegal type.
A store to an i8 will be automatically transformed into a "truncating"
to i8 store of i32. Such a truncating store means: the lower 8 bits
of this i32 value needs to be stored. When your backend sees such a
truncating store of an i32 V it will need to turn that into: read the
existing i32 value (W), replace the low 8 bits of W with the low 8
bits of V (high 8 bits on a big-endian machine), and write the new
W back.
Not necessarily. You can still make the usual data types legal. You just need to do special handling for ISD::LOAD and ISD::STORE.
Do any of the other current backends do this?
Yes, the CellSPU has the same read-modify-write semantics for stores. I'm not happy with the current way that I implemented ISD::LOAD and ISD::STORE in the backend. I'm planning on moving the ISD::LOAD and ISD::STORE code from the SPUTargetLowering class to the SSPUDAGToDAGISel class (to reduce the number of target-specific nodes.) At least you can see how things are done.
How Cell's SPU does things:
- Read and write in 16-byte chunks (vectors-at-a-time)
- To read an unaligned scalar means reading the 16-byte chunk, then rotating the chunk so that the desired value ends up in slot 0 of the vector
- To write an unaligned scalar: read the chunk, generate a shuffle mask for inserting the scalar, shuffle the vector, then store the chunk.
It's probably very similar to what you're aiming to achieve.
-scooter