Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

[Richard Henderson <rth at redhat dot com>]

On 10/08/2015 09:20 PM, Richard Biener wrote:
> On Thu, Oct 8, 2015 at 6:59 AM, Richard Henderson <rth@redhat.com> wrote:
> >          * target.def (TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID): New.
> >          * targhooks.h (default_addr_space_zero_address_valid): Declare.
> >          * targhooks.c (default_addr_space_zero_address_valid): New.
> >          * doc/tm.texi, doc/tm.texi.in: Update.
> >          * config/i386/i386.c (ix86_addr_space_zero_address_valid): New.
> >          (TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID): New.
> >          * fold-const.c (const_unop) [ADDR_SPACE_CONVERT_EXPR]: Disable
> >          folding of 0 when it is a valid address for the source space.
> >          * gimple.c (check_loadstore): Disable noticing dereference when
> >          0 is a valid address for the space.
>
> I think this is incomplete and you need to look at all places that check for
> flag_delete_null_pointer_checks (ick, the ubsan abuse looks interesting...).
> We'd best abstract that flag check somewhere, only doing the address-space
> check for ! ADDR_SPACE_GENERIC.

I did a fair survey of the uses of f_d_n_p_c.  Most of them are tests for 
explicit symbols that are weak, etc.  I suppose we should probably then check 
to see if the symbol is placed in a non-default address space, but in the 
context of the code I was working on, that never comes up.

> I also wonder about the const_unop change - if the target address-space
> has a valid 0 but the source has not then you create a valid object address
> from an invalid one?

I guess we would, but ... what else can you do when there's no invalid address?

> The check_loadstore change should instead have adjusted the
> flag_delete_null_pointer_checks guard in infer_nonnull_range_by_dereference.

Nope, that doesn't work.  You have to wait until you see the actual MEM being 
dereferenced before you can look at it's address space.


r~