<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 04/18/2016 09:52 AM, Mehdi Amini via
llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:67633203-CC62-49EE-BA7A-F66DE2E96CF3@apple.com"
type="cite">
<div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<div class="" style="word-wrap:break-word">
<div class=""><br class="">
</div>
<div class="">Initially I came across the problem with
my recent change which added an overloaded type to the
masked load/store intrinsics (<a
moz-do-not-send="true"
href="http://reviews.llvm.org/D17270" class=""><a class="moz-txt-link-freetext" href="http://reviews.llvm.org/D17270">http://reviews.llvm.org/D17270</a></a>).
The discrepancy between the name and the signature
triggers auto-upgrade bit from my patch converting an
incorrect mangling to the correct one. But later after
remapping of isomorphic types when we return to the
original type name this “updated" intrinsic name
become invalid.</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>In the same way, I'd try to avoid "autoupgrading" in this
case? I'm puzzled by the fact that round-tripping to bitcode
within the same version of LLVM triggers an "upgrade".</div>
</div>
</blockquote>
This does seem questionable. It's doesn't avoid the root issue -
which is that we're not renaming intrinsics when renaming types -
but changing this would seem reasonable to me. It sounds like we
might be relying on the upgrade functionality to paper over problems
with type renaming. (And possibly other things...?)<br>
<br>
Philip<br>
</body>
</html>