<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>Thank you both for your answers.<div><br></div><div>Actually, as a result of Duncan's comment I've been investigating how come</div><div>this code is generated. It seems to happen only with a particular version of clang.</div><div>Can't reproduce it on different machines cross-compiling for the original target</div><div>(x86_64-apple-darwin10.0.0), so I will assume I don't need to consider this</div><div>particular case.</div><div><br></div><div>I had read that part about ScalarEvolution helping with reverse engineering, but</div><div>haven't looked at it in any depth as of yet. I will eventually come to that, I guess.</div><div>Thanks for the tip.</div><div><br></div><div>Best,</div><div>Gabriel</div><div><br><hr id="zwchr"><b>De: </b>"Duncan Sands" <baldrick@free.fr><br><b>Para: </b>llvmdev@cs.uiuc.edu<br><b>Enviados: </b>Martes, 18 de Octubre 2011 19:24:15<br><b>Asunto: </b>Re: [LLVMdev] GEP instructions: is it possible to reverse-engineer array accesses?<br><br>Hi Gabriel, I suggest you don't bother with testcases like this that are doing<br>undefined things. For example, neither i nor k are initialized, so the result<br>of accessing the array is undefined. Thus the frontend can (and apparently<br>does) produce anything strange thing it does. What is more, the result aux is<br>unused, so there is no obligation to compute it correctly. I think you will<br>get more understandable results with a more sensible testcase.<br><br>Ciao, Duncan.<br><br>> As of late I am having a hard time getting my head around how array accesses<br>> are translated by Clang into LLVM IR: the often misunderstood GEP instruction.<br>> I am trying to reverse-engineer array accesses to discover the number of dimensions<br>> and actual indexes of the original, and I am beginning to wonder whether this is<br>> possible at all. To illustrate (some of) my troubles, consider the following<br>> code and<br>> the LLVM IR for both 32 and 64 bit memory addresses:<br>><br>> --<br>> original C:<br>><br>> #define N 1000<br>><br>> int main(int argc, char **argv)<br>> {<br>> int i, k;<br>> float aux, A[N][N];<br>><br>> aux = A[k][i];<br>> }<br>><br>> --<br>> 32-bit addresses LLVM IR (relevant part):<br>><br>> %4 = load i32* %i, align 4<br>> %5 = load i32* %k, align 4<br>> %6 = getelementptr inbounds [1000 x [1000 x float]]* %A, i32 0, i32 %5<br>> %7 = getelementptr inbounds [1000 x float]* %6, i32 0, i32 %4<br>> %8 = load float* %7<br>> store float %8, float* %aux, align 4<br>><br>> --<br>> 64-bit addresses LLVM IR (relevant part):<br>><br>> %4 = load i32* %i, align 4<br>> %5 = load i32* %k, align 4<br>> %6 = getelementptr inbounds [1000 x [1000 x float]]* %A, i32 0, i32 0<br>> %7 = sext i32 %5 to i64<br>> %8 = getelementptr inbounds [1000 x float]* %6, i64 %7<br>> %9 = load float* %8<br>> store float %9, float* %aux, align 4<br>><br>> --<br>><br>><br>> Why does the 64-bit addresses version use two leading 0s instead of one? I have<br>> tried reading<br>> http://llvm.org/docs/GetElementPtr.html and I don't think the explanation<br>> provided is accurate, or<br>> at least I can't see how to apply it to this particular case.<br>><br>> Besides, there is an incredible diversity of variations in how arrays can be<br>> represented and accessed<br>> in C codes, leading to my final question: is it really possible to<br>> reverse-engineer array accesses? If so,<br>> any insights?<br>><br>><br>> Thanks in advance, and best regards,<br>> Gabriel<br>><br>><br>><br>> _______________________________________________<br>> LLVM Developers mailing list<br>> LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br><br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br></div></div></body></html>