<div dir="ltr">Type information isn't preserved in LLVM IR-  the debug info will provide a best-effort, but optimizations might pull apart structures, collapse values across different variables, etc. So it's potentially lossy.<br><br>You can either use debug info (which carries as much type information as is available right now - many quality of implementation issues/areas of improvement where the debug information is lossy) or potentially insert your own intrinsics in the frontend to track the properties you care about.<br><br>- Dave</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 19, 2018 at 10:59 AM Hück, Alexander via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">
<div id="m_-4038132367093668267divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>Hello,</p>
<p><br>
</p>
<p>I am working on a pass that tries to extract type information from, say, all malloc statements in LLVM-IR (source language is C).<br>
</p>
<p>For debug code, this can be achieved by looking up the respective bitcast instruction and extracting the type from it.</p>
<p><br>
</p>
<p>However, in optimized code, the LLVM-IR omits these direct bitcasts in different scenarios (see example after the question).</p>
<p><br>
</p>
<p><span>My question now, is there any way to use, e.g., debug data or some use-def search to reliably extract the correct type information for such a malloc?</span><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>For one instance, consider the following C code:</p>
<p></p>
<div>  typedef struct {<br>
    int nvars;<br>
    int* vars;<br>
  } struct_grid;<br>
<br>
  void set(struct_grid* pgrid, int nvars, int* vars_n) {<br>
    int* new_vars;<br>
    new_vars = (int*)malloc(nvars * sizeof(int));<br>
    for (int i = 0; i < nvars; i++) {<br>
      new_vars[i] = vars_n[i];<br>
    }<br>
    pgrid->vars = new_vars;<br>
  }<br>
<br>
</div>
<p></p>
<p>Compiled with -g, we get the expected bitcast. With optimizations, we get:<br>
</p>
<p><span>  %6 = tail call i8* @malloc(i64 %5) ; the malloc, no subsequent bitcast</span></p>
<p>  ...</p>
<p><span>  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %6, i8* %10, i64 %12, i32 4, i1 false)</span></p>
<p><br>
</p>
<p>Thus, the %6 is never casted, as it is directly put into the memcpy operation.
<br>
</p>
<p><br>
</p>
<p>Only later, through some indirection when new_vars is assigned to pgrid->vars can we get the real type:</p>
<p></p>
<div>  %14 = getelementptr inbounds %struct.struct_grid, %struct.struct_grid* %0, i64 0, i32 1, !dbg !38<br>
  %15 = bitcast i32** %14 to i8**, !dbg !39<br>
  store i8* %6, i8** %15, align 8, !dbg !39, !tbaa !40</div>
<div>  ret void</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<p></p>
<p><br>
</p>
<p>Thanks in advance.<br>
</p>
</div>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>