On 04/03/15 10:41, Marc Glisse wrote:
On Wed, 4 Mar 2015, Kyrill Tkachov wrote:
Hi all,
This patch fixes PR rtl-optimization 65235.
As mentioned in bugzilla:
Combine tries to combine:
(insn 72 71 73 2 (set (reg:V2DI 117 [ D.18177 ])
(vec_concat:V2DI (reg:DI 176 [ D.18179 ])
(reg:DI 114 [ D.18168 ])))
(expr_list:REG_DEAD (reg:DI 176 [ D.18179 ])
(expr_list:REG_DEAD (reg:DI 114 [ D.18168 ])
and
(insn 104 102 105 2 (set (reg:DI 193 [ D.18168 ])
(vec_select:DI (reg:V2DI 117 [ D.18177 ])
(parallel [
(const_int 0 [0])
])))
(expr_list:REG_DEAD (reg:V2DI 117 [ D.18177 ])
(nil)))
but ends up generating:
(set (reg:DI 193 [ D.18168 ])
(reg:DI 114 [ D.18168 ]))
that is, it gets the wrong element of the vec_concat.
The problem is that in simplify-rtx it tries to get the size of the
first element, compare the requested offset against it and pick the
second element if the offset is greater than that size. If the first
element is a const_int, the size is 0, so it will always pick the second
part.
I am a bit surprised that the first element is a const_int and not reg
176, maybe that's why it doesn't reproduce on other platforms? Not that it
really matters.
Yeah, I guess combine tries various whacky combinations when it's trying to
munge things together.
The patch fixes that by calculating the size of the first element by
taking the size of the outer mode and subtracting the size of the second
element.
I wonder if we should admit that vector sizes are always a power of 2 and
use half the size of the outer mode?
Perhaps. I tried to be as defensive as possible since I'm not sure what
the restrictions
are on vec_select+vec_concat combinations.
Kyrill
I've added an assert to make sure that the second element is not also a
const_int, as a vec_concat of const_ints doesn't make sense as far as I
can see.
