This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Avoiding paradoxical subregs
- From: pinskia at gmail dot com
- To: "Paulo J. Matos" <paulo at matos-sorge dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sat, 18 Jan 2014 12:11:17 -0800
- Subject: Re: Avoiding paradoxical subregs
- Authentication-results: sourceware.org; auth=none
- References: <19EB96622A777C4AB91610E763265F463EB9B3 at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <2452971 dot KQtSWU2B5I at polaris> <19EB96622A777C4AB91610E763265F463EBA4B at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <1610262 dot jlgzldWaWu at polaris> <lbemob$aeb$1 at ger dot gmane dot org>
> On Jan 18, 2014, at 12:04 PM, "Paulo J. Matos" <paulo@matos-sorge.com> wrote:
>
> On 17/01/14 17:36, Eric Botcazou wrote:
>>> I am not implying that this is a GCC bug, unless you think
>>> WORD_REISTER_OPERATIONS should have avoided the creation of such
>>> paradoxical subreg.
>>
>> No, that's precisely the contrary, WORD_REGISTER_OPERATIONS tends to create
>> paradoxical subregs.
>
> I might then, be misunderstanding the reason to enable WORD_REGISTER_OPERATIONS. From the documentation:
>
> "Macro: WORD_REGISTER_OPERATIONS
>
> Define this macro if operations between registers with integral mode smaller than a word are always performed on the entire register. Most RISC machines have this property and most CISC machines do not. "
>
> The machine I am targeting is a 64bit vector machine. When you perform a 16 bit operation, the whole register is changed because the operation actually changes every 16bit group of the register. So it seems I should enable WORD_REGISTER_OPERATIONS.
>
> As an aside, is there any machine in gcc mainline like this?
Yes spu. It is a 128bit vector machine, operations happen in that size and compares are done in the same size.
I think you misunderstood WORD_REGISTER_OPERATIONS, it means the operation happens on the whole register in that a 16bit add is the same as a 32bit one.
Thanks,
Andrew Pinski
>
>>> What I was looking after was for a generic solution on
>>> my backend that either eliminates the use of paradoxical subregs or forces
>>> reload the transform (subreg:m (reg:n K)), where subreg is paradoxical,
>>> into a zero_extend.
>>
>> Why would it do that? That would pessimize for no clear benefit. Either the
>> paradoxical subreg is correct and there is bug in reload or it is wrong and
>> there is a bug in combine.
>
> When combine transforms:
> (zero_extend:SI (reg:HI 18))
> into
> (subreg:SI (reg:HI 18))
> it seems then to be doing something wrong. This is because the first explicitly says that bits 0-15 have the value in reg 18 and the bits 16-31 are zero. However the second means that bits 0-15 have the value in reg 18 and the bits 16-31 may or may not be defined. These are not equivalent I think. So, following your reasoning combine has a bug. Do you agree? If so, I will look for where this transformation is combine is happening.
>
>
> --
> PMatos
>