<div dir="ltr"><div>You are right Tim, it's converted later on, outside LLVM in a symbolic tree analysis phase.</div><div>Thank you.</div><div><br></div><div>Norbert<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 5, 2019 at 2:52 PM 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">On Tue, 5 Feb 2019 at 09:42, Norbert Dajka via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> I cannot get LLVM to leave an llvm::Value as ConstantInt in every case, if I pass it to IRBuilder for processing(for example through a globalvariable storing instruction).<br>
<br>
How sure are you that it's the IRBuilder doing this? It looks<br>
completely unsound to me in the general case (there's nothing tying<br>
the new globals to their original address), and I've never seen<br>
anything similar.<br>
<br>
But it looks very plausibly like what you'd get if you triggered a<br>
completely different part of some decompiler tool to decide that your<br>
accesses are generic enough to be modelled as globals in LLVM.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div>