<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 9:25 AM, Andy Ayers via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal">Function has its own FunctionType* member as well as a Type* member that it inherits from GlobalValue. The latter can be mutated but not the former, leading to potential strange inconsistencies.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">While I realize using mutateType is probably going to trigger a bunch of “you’re doing it wrong” replies, it seems like mutateType, as a necessary evil, should be virtual and do the right wrong thing for Functions too.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thoughts?</p></div></div></blockquote><div><br></div><div>I've been perpetrating some of this for the typeless/opaque pointer IR stuff (some details here: <a href="https://www.youtube.com/watch?v=OWgWDx_gB1I" target="_blank">https://www.youtube.com/watch?v=OWgWDx_gB1I</a> - or on a few threads on llvm-dev).<br><br>I got rid of that extra one in Function - thanks for noticing.<br><br>If I recall correctly, even before my work, it wasn't possible to rely solely on mutateType of the operands  so various special cases have been added (ValueMapper.cpp is a good example of some of these special cases)<br><br>I'm not sure why those issues might not have come up when dealing with Globals. Perhaps you have some examples (eg: linking bitcode with globals - where the value type gets out of sync with the pointer type? Maybe if we add some more assertions in to check the two values are in sync we'd find cases where they've gotten out of sync?)</div></div></div></div>