llvm dev - Mar 2009 - [LLVMdev] byte store requires read-modify-write sequence

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