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: PING [PATCH] PR middle-end/74113: Don't limit piecewise move to MAX_FIXED_MODE_SIZE


On Mon, Aug 22, 2016 at 9:16 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Aug 11, 2016 at 1:38 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>> alignment_for_piecewise_move is called only with MOVE_MAX_PIECES or
>> STORE_MAX_PIECES, which are the number of bytes at a time that we
>> can move or store efficiently.  We should call mode_for_size without
>> limit to MAX_FIXED_MODE_SIZE, which is an integer expression for the
>> size in bits of the largest integer machine mode that should actually
>> be used, may be smaller than MOVE_MAX_PIECES or STORE_MAX_PIECES, which
>> may use vector register.
>>
>> MAX_BITSIZE_MODE_ANY_INT is only defined for i386 and everyone else uses
>> the default.  The widest mode for integer computation is determined by
>> MAX_FIXED_MODE_SIZE, not by MAX_BITSIZE_MODE_ANY_INT.  OImode and XImode
>> can be used for load and store, including constant integers.  Remove
>> MAX_BITSIZE_MODE_ANY_INT from i386 to avoid any potential problems for
>> constant integers > TImode.

This enlarges wide(st)_int storage from 192bits to 576bits and thus
isn't really acceptable.

MAX_BITSIZE_MODE_ANY_INT was invented for a reason.  Iff a target wants to use
vector registers for moving storage we should use vector modes to perform said
operations (and thus have vector constants here).  IMHO we should work towards
_not_ requiring integer modes for each supported vector size not the
other way around.

Richard.

>> Tested on i686 and x86-64.  OK for trunk?
>>
>>
>> H.J.
>> ---
>>         PR middle-end/74113
>>         * expr.c (alignment_for_piecewise_move): Call mode_for_size
>>         without limit to MAX_FIXED_MODE_SIZE.
>>         * config/i386/i386-modes.def (MAX_BITSIZE_MODE_ANY_INT): Removed.
>> ---
>>  gcc/config/i386/i386-modes.def | 5 -----
>>  gcc/expr.c                     | 2 +-
>>  2 files changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/gcc/config/i386/i386-modes.def b/gcc/config/i386/i386-modes.def
>> index d524313..61a1f08 100644
>> --- a/gcc/config/i386/i386-modes.def
>> +++ b/gcc/config/i386/i386-modes.def
>> @@ -98,10 +98,5 @@ POINTER_BOUNDS_MODE (BND64, 16);
>>  INT_MODE (OI, 32);
>>  INT_MODE (XI, 64);
>>
>> -/* Keep the OI and XI modes from confusing the compiler into thinking
>> -   that these modes could actually be used for computation.  They are
>> -   only holders for vectors during data movement.  */
>> -#define MAX_BITSIZE_MODE_ANY_INT (128)
>> -
>>  /* The symbol Pmode stands for one of the above machine modes (usually SImode).
>>     The tm.h file specifies which one.  It is not a distinct mode.  */
>> diff --git a/gcc/expr.c b/gcc/expr.c
>> index 46de35f..826fd9b 100644
>> --- a/gcc/expr.c
>> +++ b/gcc/expr.c
>> @@ -692,7 +692,7 @@ alignment_for_piecewise_move (unsigned int max_pieces, unsigned int align)
>>  {
>>    machine_mode tmode;
>>
>> -  tmode = mode_for_size (max_pieces * BITS_PER_UNIT, MODE_INT, 1);
>> +  tmode = mode_for_size (max_pieces * BITS_PER_UNIT, MODE_INT, 0);
>>    if (align >= GET_MODE_ALIGNMENT (tmode))
>>      align = GET_MODE_ALIGNMENT (tmode);
>>    else
>> --
>> 2.7.4
>>
>
> PING.
>
>
> --
> H.J.


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