On 1/8/19 2:08 PM, Jakub Jelinek wrote:
> On Tue, Jan 08, 2019 at 01:52:35PM +0100, Jakub Jelinek wrote:
>>> 2019-01-08 Martin Liska <mli...@suse.cz>
>>>
>>> PR tree-optimization/88753
>>> * tree-switch-conversion.c (switch_conversion::build_one_array):
>>> Come up with local variable constructor. Convert first to
>>> type of constructor values.
>>
>> Why is the testcase missing?
>
> Oh, one more thing. What happens if the index is wider (higher precision)
> than the type of the constructor elts? At least for the two_value_replacement
> optimization in phiopt, I'm using the wider of the two types for the
> arithmetics (conditionally unsigned if not proven not to overflow).
> Shouldn't that be the case in this optimization too?
I've been running for quite some GCC bootstrap with:
diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c
index c3f2baf39d7..c774350b497 100644
--- a/gcc/tree-switch-conversion.c
+++ b/gcc/tree-switch-conversion.c
@@ -100,6 +100,7 @@ switch_conversion::collect (gswitch *swtch)
max_case = gimple_switch_label (swtch, branch_num - 1);
m_range_min = CASE_LOW (min_case);
+ gcc_assert (operand_equal_p (TYPE_SIZE (TREE_TYPE (m_range_min)), TYPE_SIZE
(TREE_TYPE (m_index_expr)), 0));
if (CASE_HIGH (max_case) != NULL_TREE)
m_range_max = CASE_HIGH (max_case);
else
and I haven't triggered the assert.
>
> With using just the constructor elt type, do you count on the analysis to
> fail if starting with casting the index to the elt type (or unsigned variant
> thereof) affects the computation?
So hopefully the situation can't happen. Note that if it happens we should not
generate wrong-code, but we miss an opportunity.
Martin
>
> Jakub
>
