[LLVMdev] Pointer vs Integer classification (was Re: make DataLayout a mandatory part of Module)

[Philip Reames]

On 02/14/2014 05:55 PM, Philip Reames wrote:
> On 02/10/2014 05:25 PM, Nick Lewycky wrote:
>>
>> 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.
> I agree this is possible, even with my proposal.  In fact, we already 
> have a stack colouring pass in tree which does exactly what your 
> example illustrates.  However, this is done well after CodeGenPrepare 
> and is thus after we start relaxing canonical form anyway.
>
> A couple of other transforms which could potentially be problematic:
> - load widening
> - vectorization (when the vector element type looses the 'pointerness')
>
> In each of these cases, we have clear ways of expressing the 
> transformation in ways which preserve type information.  (i.e. struct 
> types, vector element types, etc..)  I would hope we could move 
> towards these cleaner representations.  (Note: I haven't checked the 
> current implementations.  I should do so.)
>
> My view of this is that any optimization which lost type information 
> in such a manner without good cause would be poor style to begin 
> with.  I would hope that patches to remove such information loss would 
> be accepted so long as there was a reasonable alternative.  (I'm 
> assuming this is already true; if it's not, let me know.)
>
> (In case it's not clear, being past CodeGenPrepare and lowering for a 
> specific target would be a "good reason".)
One thing I thought of over the weekend: all of the transformations 
discussed above are already illegal unless they explicitly preserve the 
address space of the pointer.

Doesn't prevent them from existing, but it does increase the odds 
they're already buggy.

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140218/98d3bde9/attachment.html>