* tree-ssa-address.c (move_hint_to_base): Remove arg TYPE. All
callers changed. Don't cast the new base to a pointer type.
(addr_to_parts): If the base has an integer type, use that instead
of sizetype for calculations.
===================================================================
@@ -443,12 +443,10 @@ move_fixed_address_to_symbol (struct mem
/* If ADDR contains an instance of BASE_HINT, move it to PARTS->base. */
static void
-move_hint_to_base (tree type, struct mem_address *parts, tree base_hint,
- aff_tree *addr)
+move_hint_to_base (struct mem_address *parts, tree base_hint, aff_tree *addr)
{
unsigned i;
tree val = NULL_TREE;
- int qual;
for (i = 0; i < addr->n; i++)
{
@@ -463,13 +461,7 @@ move_hint_to_base (tree type, struct mem
if (i == addr->n)
return;
- /* Cast value to appropriate pointer type. We cannot use a pointer
- to TYPE directly, as the back-end will assume registers of pointer
- type are aligned, and just the base itself may not actually be.
- We use void pointer to the type's address space instead. */
- qual = ENCODE_QUAL_ADDR_SPACE (TYPE_ADDR_SPACE (type));
- type = build_qualified_type (void_type_node, qual);
- parts->base = fold_convert (build_pointer_type (type), val);
+ parts->base = val;
aff_combination_remove_elt (addr, i);
}
@@ -639,7 +631,7 @@ addr_to_parts (tree type, aff_tree *addr
tree base_hint, struct mem_address *parts,
bool speed)
{
- tree part;
+ tree part, int_type;
unsigned i;
parts->symbol = NULL_TREE;
@@ -671,21 +663,29 @@ addr_to_parts (tree type, aff_tree *addr
there is no reliable way how to distinguish between pointer and its
offset, this is just a guess. */
if (!parts->symbol && base_hint)
- move_hint_to_base (type, parts, base_hint, addr);
+ move_hint_to_base (parts, base_hint, addr);
if (!parts->symbol && !parts->base)
move_pointer_to_base (parts, addr);
+ /* The call to move_hint_to_base may have promoted an integer to the base.
+ Since addresses in different address spaces can have different sizes, do
+ not cast to sizetype in that case, but use the type of the base. */
+ if (parts->base && TREE_CODE (TREE_TYPE (parts->base)) == INTEGER_TYPE)
+ int_type = TREE_TYPE (parts->base);
+ else
+ int_type = sizetype;
+
/* Then try to process the remaining elements. */
for (i = 0; i < addr->n; i++)
{
- part = fold_convert (sizetype, addr->elts[i].val);
+ part = fold_convert (int_type, addr->elts[i].val);
if (addr->elts[i].coef != 1)
- part = fold_build2 (MULT_EXPR, sizetype, part,
- wide_int_to_tree (sizetype, addr->elts[i].coef));
+ part = fold_build2 (MULT_EXPR, int_type, part,
+ wide_int_to_tree (int_type, addr->elts[i].coef));
add_to_parts (parts, part);
}
if (addr->rest)
- add_to_parts (parts, fold_convert (sizetype, addr->rest));
+ add_to_parts (parts, fold_convert (int_type, addr->rest));
}
/* Force the PARTS to register. */
This is a followup fix for the patches from PR41857, which contained a bug that is exposed by the ptx backend. The problem is finding the right pointer type for a mem_ref during ivopts. The original problem was that on spu-elf, __ea pointers are 64 bit while sizetype is 32 bit. During ivopts, pointer types are typically replaced by unsigned integers in computations, and in the original testcase we have an aff_tree containing only one long long element, but no pointer base, and addr_to_parts casts everything to sizetype, losing parts of the address. To fix that, code was introduced to promote one of the elements of the aff_tree to become the base, cast it to a pointer of an appropriate type, and thus avoid the conversion to sizetype for that element. This element is the base_hint, which is chosen based on the candidate's base_object. The problem lies in the following code in move_hint_to_base: /* Cast value to appropriate pointer type. We cannot use a pointer to TYPE directly, as the back-end will assume registers of pointer type are aligned, and just the base itself may not actually be. We use void pointer to the type's address space instead. */ qual = ENCODE_QUAL_ADDR_SPACE (TYPE_ADDR_SPACE (type)); type = build_qualified_type (void_type_node, qual); parts->base = fold_convert (build_pointer_type (type), val); This is confused about address spaces. We can get here with either an integer (for the the original testcase in 4.5, it's a long long that holds the pointer value), but I think we can also arrive here with a pointer. Assuming a normal machine, if it's a long long created by ivopts, TYPE_ADDR_SPACE should be just generic, and if it's some other pointer, we should be looking at TYPE_ADDR_SPACE (TREE_TYPE (type)). Thus, the code seems essentially unnecessary, but - up to this point - harmless. On ptx however, local variables have an address space, and the above code picks that up and incorrectly places it on the pointer destination type. The following patch reworks this area - instead of trying to find a proper pointer type, it just recognizes the case where an integer is promoted to be the base, and performs all calculations in that type rather than sizetype. That also seems to be an additional bugfix over the original change, which could still lose address bits in the index. I've verified that this produces the same assembly for the original testcase on spu-elf with the gcc-4_5-branch, and it solves the problems I was seeing on ptx. Bootstrapped and tested on x86_64-linux. Ok? Bernd