> On Jan 18, 2014, at 12:04 PM, "Paulo J. Matos" <pa...@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 >
