[llvm-dev] [RFC] NewGVN

[David Chisnall via llvm-dev]

On 16 Nov 2016, at 19:03, Davide Italiano <davide at FreeBSD.org> wrote:
> 
>>> 
>>> For our target, this is only sound if you can show that the pointer was
>>> used to read all of the bytes that you are loading (we have byte-granularity
>>> memory safety).  Old GVN has no hooks for targets to specify whether this is
>>> safe and so is implicitly assuming a page-based MMU.  This optimisation is
>>> also unsound for M-profile ARM cores, though will fail occasionally there,
>>> whereas it fails deterministically for us.
>>> 
>>> Does it make any assumptions about the layout of memory in pointers?
>> 
> 
> Which assumptions are you thinking of?

My last merge from upstream was about a year ago (and a new one is long overdue), but there were issues where GVN was assuming that if it did a load of a pointer then a ptrtoint, then a truncation, that it would get the same result as doing a narrower load.  This is not the case in any platform where pointers are not simply integers (i.e. where you actually need inttoptr / ptrtoint instead of bitcast).

David