Re: [PATCH] Merge adjacent stores of constants (PR middle-end/22141)

[Adam Nemet <anemet at caviumnetworks dot com>]

Jakub Jelinek writes:
> etc., it would have to be a special very late pass (during TER or around
> that time).  Something can't be done at the RTL level (e.g. we need to
> ressurrect in some way optimize_bit_field_compare for PR37248, if
> BIT_FIELD_REF isn't appropriate, then for very small structs using
> VIEW_CONVERT_REF to some integer type and masking, if the struct
> is large, then by taking address of it, casting to a REF_ALL pointer
> and reading the bitfield bits together that way.

Actually we have a late tree pass in our 4.1-based compiler that tries to
merge adjacent constant bitfield stores.  It also handles unions WRT
overlapping "bitfields" (Octeon HW communicates with 64-bit bitfields and our
system code likes to zero out the whole 64-bit structure before filling
individual fields).  I can update this pass for 4.5 and submit.  I was just
somehow under the impression that there were plans to do this in the folder.

> If MIPS supports unaligned accesses and they are just twice as slow as
> aligned, I'd say it shouldn't have defined STRICT_ALIGNMENT.

Well, it supports it but not with the same load/store instructions, i.e. you
need to expand them through bit-extract/insert.  Also HImode accesses are not
supported.

> In any case, I of course appreciate suggestions how to do a reasonable
> cost model for this, but I'd say it can be done incrementally when the main
> patch is in (if it is approved).

Absolutely, I was just looking at this long term and see how we can use this
on MIPS.

Thanks for you work.

Adam