This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING [PATCH] PR middle-end/74113: Don't limit piecewise move to MAX_FIXED_MODE_SIZE
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 23 Aug 2016 09:38:23 +0200
- Subject: Re: PING [PATCH] PR middle-end/74113: Don't limit piecewise move to MAX_FIXED_MODE_SIZE
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOoxG-FUfeJfiA9ad1a4zb=n-ho7D1=u9ttoXfR5PnmWLw@mail.gmail.com>
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.