On Tue, Oct 13, 2015 at 10:59 PM, Richard Henderson <r...@redhat.com> wrote:
> On 10/14/2015 02:49 AM, Jeff Law wrote:
>>
>> The problem here is we don't know what address space the *0 is going to
>> hit,
>> right?
>
>
> Correct, not before we do the walk of stmt to see what's present.
>
>> Isn't that also an issue for code generation as well?
>
>
> What sort of problem are you thinking of? I haven't seen one yet.
The actual dereference of course has a properly address-space qualified zero.
Only your walking depends on operand_equal_p to treat different address-space
zero addresses as equal (which they are of course not ...):
int
operand_equal_p (const_tree arg0, const_tree arg1, unsigned int flags)
{
...
/* Check equality of integer constants before bailing out due to
precision differences. */
if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) == INTEGER_CST)
{
/* Address of INTEGER_CST is not defined; check that we did not forget
to drop the OEP_ADDRESS_OF/OEP_CONSTANT_ADDRESS_OF flags. */
gcc_checking_assert (!(flags
& (OEP_ADDRESS_OF | OEP_CONSTANT_ADDRESS_OF)));
return tree_int_cst_equal (arg0, arg1);
}
but only later we do
/* We cannot consider pointers to different address space equal. */
if (POINTER_TYPE_P (TREE_TYPE (arg0))
&& POINTER_TYPE_P (TREE_TYPE (arg1))
&& (TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (arg0)))
!= TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (arg1)))))
return 0;
So "fixing" that would make the walker only look for default
address-space zero dereferences.
I think we need to fix operand_equal_p anyway because 0 is clearly not
equal to 0 (only if
they convert to the same literal)
Richard.
>
> r~
