This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BLK mode move pattern ?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]