LLVA and WCET Analysis

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

LLVA and WCET Analysis

Fabian Scheler
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.

Thanks in advance, Fabian
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVA and WCET Analysis

Andrew Lenharth
On 4/2/07, Fabian Scheler <[hidden email]> 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).

Andrew
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVA and WCET Analysis

Vikram S. Adve

On Apr 3, 2007, at 10:55 AM, Andrew Lenharth wrote:

> On 4/2/07, Fabian Scheler <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVA and WCET Analysis

Fabian Scheler
> > 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVA and WCET Analysis

Vikram S. Adve
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev