This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [middle-end][PATCH] Update alignment_for_piecewise_move
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Bernd Schmidt <bschmidt at redhat dot com>
- Cc: "H.J. Lu" <hongjiu dot lu at intel dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Tue, 26 Apr 2016 11:39:56 -0700
- Subject: Re: [middle-end][PATCH] Update alignment_for_piecewise_move
- Authentication-results: sourceware.org; auth=none
- References: <20160426153346 dot GA18201 at intel dot com> <87wpnkdydd dot fsf at googlemail dot com> <571FB407 dot 2090502 at redhat dot com>
On Tue, Apr 26, 2016 at 11:31 AM, Bernd Schmidt <bschmidt@redhat.com> wrote:
> On 04/26/2016 08:21 PM, Richard Sandiford wrote:
>>
>> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>>>
>>> I am working a patch to enable SSE, AVX and AVX512 for memcpy/memset
>>> optimization. x86 backend defines MAX_BITSIZE_MODE_ANY_INT to 128
>>> to keep the OI and XI modes from confusing the compiler into thinking
>>> that these modes could actually be used for computation. But the OI
>>> and XI modes can be used for data movement with vector instructions.
>>
>>
>> But doesn't this then open the possibility that a memset or memcpy
>> will be seen as a "normal" integer operation? Routines like
>> simplify_immed_subreg could in principle create a constant integer
>> for the stored value, which could then be treated by later passes as
>> a wide_int, breaking the MAX_BITSIZE_MODE_ANY_INT assumption.
>>
>> Couldn't we move to allowing vector modes instead? That seems better
>> than having to pander to the current situation in which every vector
>> effectively needs an associated integer mode.
>
>
> I'm actually working on a patch in this area. Haven't gotten to the point of
> allowing vector modes yet, but it's something that I've had on my mind; I
> think it would be a good idea.
>
I am looking forward to seeing your patch.
Thanks.
--
H.J.