<div dir="ltr"><div dir="ltr">On Mon, 29 Nov 2021 at 18:15, Matt Arsenault <<a href="mailto:arsenm2@gmail.com" target="_blank">arsenm2@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>This is true, but this isn’t directly related to this change. If the target does not have no-op conversions between a given pair of address spaces, the original code was broken to begin with. This change does not allow introducing new illegal address space conversions that were not already present in the original program. It’s garbage in, garbage out. If the target can’t really reinterpret these pointers, it would be UB on access.</div></div></div></blockquote><div><br></div><div>Ah, I see.</div><div><br></div><div>So IIUC, adding the casts in the first place would have to know about target address spaces, but this specific change only allows eliding the inttoptr cast in the specific case where the address spaces have the same data layout?</div><div><br></div><div>Assuming the initial cast was legal to begin with, this looks sensible to me.</div><div><br></div><div>I was worried this would allow (encourage?) front-ends and other passes to add an address space cast where none (could have) existed in the first place.</div><div><br></div><div>Sorry for the noise.</div><div><br></div><div>--renato</div></div></div>