BLK mode move pattern ?

[Jeff Law]

On 10/12/2016 03:08 AM, Martien de Jong wrote:
> Hi,
>
> This is a compiler development question. I may be addressing the
> wrong mailing list. If so, could you please point me to the
> appropriate one?
>
> I'm trying to use quad-word load and store instructions on a 32 bit
> SPARC derivative. I just want to use them to shift small packets
> with a few instructions.
>
> The memory and registers need to be quad-word aligned, for which
> I added new constraints along the lines of similar ones for double
> word load and store. I created a movti pattern using them.  However,
> as soon as I enable TI using
>
> targetm->scalar_mode_supported_p(TImode) -> true,
>
> the compiler is convinced that I want full-fledged quad-word integer
> type and that it can use it as carrier for all kind of quad word types
> like vector(4 * int) and double complex. I also get endless conflicts
> with unaligned quad registers in register calling conventions, many
> of which in the libgcc support functions.
>
> One central problem I keep seeing is this assert in gen_highpart():
>
>   /* This case loses if X is a subreg.  To catch bugs early,
>      complain if an invalid MODE is used even in other cases.  */
>   gcc_assert (msize <= UNITS_PER_WORD
>               || msize == (unsigned int) GET_MODE_UNIT_SIZE (GET_MODE(x)));
>
> when tryiZZng to split TImode to DImode. It looks as if this wasn't
> intended to be used on a 32 bit architecture. However, disabling the
> assert doesn't seem to introduce any further problems and solving a
> lot of others. (It seems to automagically split TI to DI and then
> DI to SI).  What will I 'lose if X is a subreg'?. The prospect of
> needing to specify a host of new split rules doesn't appeal to me.
>
> Another problem I have seen is a failing expand on TI mode
> multiply, which it can't seem to split.
>
> Given all this trouble and the fact that I really don't want 128bit
> arithmetic, is there a way that I can specify some specific patterns
> for memory transfers only, in particular without enabling TImode?
>
> Ideally, I would like to say (something like, never can remember
> the exact syntax):
>
> typedef struct {
>     unsigned w[4];
> } __attribute__ ((align(16))) __attribute__ (mode(BLKmode)) bits128_t;
>
> and specify a 'movblk' pattern that is used whenever appropriate,
> also in e.g. the struct copy breakdown (move_by_pieces) if memory
> alignment is right.  I know that BLKmode is the default for
> aggregates and can't be assigned like this. I just want the effect.
>
> I would be happy to write some dedicated expand code, but I don't
> know where to start. Also, a pointer into the documentation related
> to the subject would be much appreciated.
>
> BTW, I'm on gcc 4.9, which is forced by the external requirement to be
> compatible with Debian 8' version of gcc.
I'd look at defining a movmem/movstr patterns.

That may in turn involve creating a pattern which implements movti, but 
don't call it movti.  Lots of stuff is going to trigger off the 
existence of movXX patterns, which is precisely what you're trying to 
avoid.  So change the name of your pattern from "movti" to 
"movti_internal" or somesuch.  You can then generate that pattern via 
gen_movti_internal (args...)





jeff