[LLVMdev] make DataLayout a mandatory part of Module

[David Chisnall]

On 11 Feb 2014, at 01:25, Nick Lewycky <nlewycky at google.com> wrote:

> Your IR won't do any shifty pointer-int conversion shenanigans, and you want some assurance that an optimization won't introduce them, or that if one does then you can call it out as a bug and get it fixed. I think that's reasonable, but I also think it's something we need to put forth before llvm-dev.
> 
> Note that pointer-to-int conversions aren't necessarily just the ptrtoint/inttoptr instructions (and constant expressions), there's also casting between { i64 }* and { i8* }* and such. Are there legitimate reasons an optz'n would introduce a cast? I think that anywhere in the mid-optimizer, conflating integers and pointers is only going to be bad for both the integer optimizations and the pointer optimizations.
> 
> It may make sense as part of lowering -- suppose we find two alloca's, one i64 and one i8* and find that their lifetimes are distinct, and i64 and i8* are the same size, so we merge them. Because of how this would interfere, I don't think this belongs anywhere in the mid-optimizer, it would have to happen late, after lowering. That suggests that there's a point in the pass pipeline where the IR is "canonical enough" that this will actually work.
> 
> Is that reasonable? Can we actually guarantee that, that any pass which would break this goes after a common gc-root insertion spot? Do we need (want?) to push back and say "no, sorry, make GC roots better instead"?

I am not currently working on GC, but I am working on a back end for an architecture in which pointer integrity is enforced in hardware and pointers and integers have different representations and different representations and so I would also find much of this contract for optimisations useful.  Round tripping via an int involves data loss on my architecture and having optimisations insert these can be annoying (and break security properties).  I imagine that the situation is similar for most software-enforced memory safety tools, not just GC.

David