On 17/01/14 17:36, Eric Botcazou wrote:
I am not implying that this is a GCC bug, unless you think
WORD_REGISTER_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?
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
