On 10/08/2015 09:20 PM, Richard Biener wrote:
On Thu, Oct 8, 2015 at 6:59 AM, Richard Henderson <r...@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~
