This is the mail archive of the gcc-patches@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: [PATCH][rtlanal.c][BE][1/2] Fix vector load/stores to not use ld1/st1


Eric Botcazou <ebotcazou@adacore.com> writes:
>> What do you think we should relax it to though?  Obviously there's a balance
>> here between relaxing things enough and not relaxing them too far (so that
>> the EImode AArch64 thing I mentioned is still a noisy failure, for
>> example). ISTM the patch deals with the only significant case that is
>> obviously safe for modes that are not a power of 2 in size.
>
> Apparently the change wants to accept general subregs with not only modes 
> whose sizes are multiple of each other but also whose sizes are multiple of a 
> common large enough value.  That clearly goes against:
>
>   /* This should always pass, otherwise we don't know how to verify
>      the constraint.  These conditions may be relaxed but
>      subreg_regno_offset would need to be redesigned.  */
>   gcc_assert ((GET_MODE_SIZE (xmode) % GET_MODE_SIZE (ymode)) == 0);
>   gcc_assert ((nregs_xmode % nregs_ymode) == 0);
>
> so I think that we should formulate the new requirement and implement it in 
> the main part of the function, instead of adding it as a kludge.

Please be more specific though.  If you don't think the patch is correct,
what do you think the requirement should be and how should it be integrated
into the existing checks?

E.g. the assert is there because the main calculation is based on:

  /* Size of ymode must not be greater than the size of xmode.  */
  mode_multiple = GET_MODE_SIZE (xmode) / GET_MODE_SIZE (ymode);
  gcc_assert (mode_multiple != 0);

which clearly isn't a useful value if the division isn't exact.
Do you mean that, since mode_multiple isn't correct for the
DI-of-a-CI case, we should reformulate the end of the function
to avoid using mode_multiple at all?

Thanks,
Richard


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