<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 19, 2019 at 11:27 AM Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> So at a high level I think we should put the serialization and Instruction<br>
>> changes in sooner rather than later, giving us a largely undocumented[2] dialect<br>
>> of IR with opaque pointers that we can write tests against to upstream the rest<br>
>> of what I've done (and others can use to continue work in parallel if they're<br>
>> inclined).<br>
><br>
> My, admittedly rather vague, plan was to change the API down to the point where there was only a primitive for "propagating pointee type from one place to another" but without the ability to query it otherwise - well, with a deprecated way to query it that we could chase down calls to as the main migration. Once we got to zero "getElementType" callers we could figure out the actual IR migration piece.<br>
><br>
> Do you think that wouldn't be viable & that introducing the new opaque pointer type sooner would be better/more viable?<br>
<br>
I think it'd be viable, but would turn many of the patches into NFC<br>
with no way to test them.</blockquote><div><br>Hmm, I get where you're coming from & would hope they'd sort of be NFC - but yeah, if we made these changes with an opaque pointer type available, we could write tests demonstrating the support for opaque pointers by writing test cases with mismatched pointers... except they wouldn't be mismatched anyway because there'd be no type. So I guess at best we could demonstrate a new optimization available with the opaque pointers that couldn't be expressed with typed pointers.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I'm quite happy to do that for strictly<br>
obvious changes, but I get a bit more nervous when we get to larger<br>
scale refactorings. I'd like to be able to do more than just hope<br>
people don't regress to getElementPtr, ideally.<br></blockquote><div><br>Please go ahead with whatever way you think works best - I can totally see it both/either way.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But I think that approach definitely pushes the IR changes from<br>
short/medium term to medium term at the very least, and I'll pursue<br>
the kind of patches you're suggesting for now. Perhaps revisit the<br>
question when things start getting tricky.<br>
<br>
> Is byval already fixed/changed? I may've lost track of some of these changes, but I knew that was next on my list. (& how was byval addressed - byval(<ty>) or byval(byte count)? I guess inalloca goes/should go the same way as byval)<br>
<br>
byval(<ty>) is in, and used by Clang now. In retrospect I should have<br>
done inalloca at the same time, but for some reason I decided it<br>
wasn't necessary. I think it'll need the same conversion, and then<br>
both must be made compulsory.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div></div>