<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 02/14/2014 05:55 PM, Philip Reames
wrote:<br>
</div>
<blockquote cite="mid:52FEC90C.3030905@philipreames.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 02/10/2014 05:25 PM, Nick Lewycky wrote:<br>
<blockquote
cite="mid:CADbEz-gPTzM0saPA5X9_SM0mqTyARaeTE77=a75fm9cSu5J4yw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
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. <br>
<br>
A couple of other transforms which could potentially be
problematic:<br>
- load widening<br>
- vectorization (when the vector element type looses the
'pointerness')<br>
<br>
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.)<br>
<br>
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.)<br>
<br>
(In case it's not clear, being past CodeGenPrepare and lowering
for a specific target would be a "good reason".)<br>
</blockquote>
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. <br>
<br>
Doesn't prevent them from existing, but it does increase the odds
they're already buggy. <br>
<br>
Philip<br>
</body>
</html>