On Apr 3, 2007, at 10:55 AM, Andrew Lenharth wrote:> On 4/2/07, Fabian Scheler <fabian.scheler at gmail.com> wrote: >> Hello everybody, >> >> I'm curious whether there have been any attempts to perform >> performance analysis on the LLVA level. I am interested in the >> derivation of flow-facts (loop bounds etc. - what about the >> value-range-propagation pass I read about on this list some time ago) >> but even more I am interested in exec-time modeling (how long does it >> take to execute a bunch of LLVA instructions on particular processor) >> for the LLVA. I am glad about every pointer I can get. > > If you are asking about LLVA not LLVM, see > http://llvm.org/pubs/2006-06-18-WIOSCA-LLVAOS.html > > LLVA specifically is refering to a research project offshoot of llvm. > LLVM instructions do not have 1:1 mappings to native instructions > (sometimes multiple llvm instructions map to fewer native insts, > sometimes the other way around).That's correct, and furthermore, LLVA (now called SVA = Secure Virtual Architecture) uses essentially the same virtual instruction set as LLVM, so they have the same difficulty. --Vikram
> > LLVA specifically is refering to a research project offshoot of llvm. > > LLVM instructions do not have 1:1 mappings to native instructions > > (sometimes multiple llvm instructions map to fewer native insts, > > sometimes the other way around). > > That's correct, and furthermore, LLVA (now called SVA = Secure > Virtual Architecture) uses essentially the same virtual instruction > set as LLVM, so they have the same difficulty.Hm, when writing LLVA I rather meant this publication http://llvm.org/pubs/2003-10-01-LLVA.html Maybe the used abbreviations meanwhile changed or I mixed up something else. Regarding the fact, that it is not possible to have a 1:1 mapping between LLVM instructions and native code instructions in the general case. That is clear, it is the same problem as it is with Java Byte Code. Some work dealing with WCET analysis of Java Byte Code already has been done: Iain Bate, Guillem Bernat, Greg Murphy, Peter Puschner: Low-Level Analysis of a Portable Java Byte Code WCET Analysis Framework Guillem Bernat, Alan Burns, Andy Wellings: Portable Worst-Case Execution Time Analysis Using Java Byte Code I just wondered if anybody did something similar for the LLVM instruction set, but apparently this seems not to be the case. Ciao, Fabian
I do not know of any such work for LLVM. Also, WCET for LLVM should be much simpler than for Java bytecode because LLVM is more low-level and translates to a very small (and highly predictable for any specific target) number of operations. Of course, the general problems also present at the machine code level still remain -- cache misses, branch mispredicts, exceptions, etc. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Apr 3, 2007, at 3:22 PM, Fabian Scheler wrote:>>> LLVA specifically is refering to a research project offshoot of >>> llvm. >>> LLVM instructions do not have 1:1 mappings to native instructions >>> (sometimes multiple llvm instructions map to fewer native insts, >>> sometimes the other way around). >> >> That's correct, and furthermore, LLVA (now called SVA = Secure >> Virtual Architecture) uses essentially the same virtual instruction >> set as LLVM, so they have the same difficulty. > > Hm, when writing LLVA I rather meant this publication > > http://llvm.org/pubs/2003-10-01-LLVA.html > > Maybe the used abbreviations meanwhile changed or I mixed up something > else. Regarding the fact, that it is not possible to have a 1:1 > mapping between LLVM instructions and native code instructions in the > general case. That is clear, it is the same problem as it is with Java > Byte Code. Some work dealing with WCET analysis of Java Byte Code > already has been done: > > Iain Bate, Guillem Bernat, Greg Murphy, Peter Puschner: > Low-Level Analysis of a Portable Java Byte Code WCET Analysis > Framework > > Guillem Bernat, Alan Burns, Andy Wellings: > Portable Worst-Case Execution Time Analysis Using Java Byte Code > > I just wondered if anybody did something similar for the LLVM > instruction set, but apparently this seems not to be the case. > > Ciao, Fabian > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev