On 10/22/2015 01:58 AM, Richard Biener wrote:
On Thu, Oct 22, 2015 at 5:12 AM, Sandra Loosemore
<san...@codesourcery.com> wrote:
On 10/20/2015 03:27 PM, Richard Henderson wrote:
+@deftypefn {Target Hook} bool TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID
(addr_space_t @var{as})
+Define this to modify the default handling of address 0 for the
+address space. Return true if 0 should be considered a valid address.
+@end deftypefn
+
I'm confused by this new hook. How does it interact with
-fdelete-null-pointer-checks? E.g. nios2-elf defaults
flag_delete_null_pointer_checks to 0 precisely because address 0 is
legitimate on that target. The avr and cr16 backends simply override
flag_delete_null_pointer_checks. Do backends that already frob one thing
need to frob the other as well? Are there any changes to the user
documentation for -fdelete-null-pointer-checks required?
I suppose a cleanup possibility would be to get rid of that "abuse" of
flag_delete_null_pointer_checks and make all targets now defining that to zero
instead implement the hook above but for the default address-space.
And then make all places checking for flag_delete_null_pointer_checks (or
at least some) use the target hook instead.
If it's not possible to integrate the two mechanisms somehow, can we at
least improve the documentation of the new hook to better explain how it
interacts with flag_delete_null_pointer_checks? E.g. I'm concerned that
if you provide a hook implementation that always returns true, it won't
really disable all optimizations that depend on the assumption that
accesses to address 0 will trap, and that you still need to set
flag_delete_null_pointer_checks too. The language I quoted above is
pretty vague about what compiler actions are controlled by this flag,
and if it only controls a subset of assumptions made about address zero
it ought to be more explicit about what subset that is.
-Sandra
