> On Jul 5, 2018, at 9:01 PM, Paul Koning <paulkon...@comcast.net> wrote:
>
>
>
>> On Jul 5, 2018, at 6:47 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>>
>>> So back to the previous one: anything I can do about a 24 bit field getting
>>> split into three movqi rather than a movqi plus a movhi? That happens
>>> during RTL expand, I believe.
>>
>> Yes, this one doesn't look as hopeless as the store merging issue. A way of
>> tackling it would be to do a side-by-side debugging of a compiler built for
>> a
>> similar target for which only 2 stores are generated.
>
> I'll try xstormy16 since that's also 16 bit words, strict alignment.
>
> Then again, I fed the code to GCC for VAX and it also produces a sequence of
> 3 separate byte stores. No mixed endians there.
Xstormy does 3 mov.b also. For that matter, so does the x86 target (both -m32
and -m64). Hm.
paul
