[LLVMdev] Software Pipelineing | Embedded C Extensions

Evan Cheng evan.cheng at apple.com
Thu Feb 15 11:44:19 PST 2007


On Feb 14, 2007, at 2:18 AM, Dietmar Ebner wrote:

> Pertti,
>
> On Feb 13, 2007, at 7:34 PM, Pertti Kellomäki wrote:
>> Dietmar Ebner wrote:
>>>  most of the work seems to be done in an architecture dependent,
>>> very low-
>>> level IR. are there any efforts to generalize architecture
>>> independent portions
>>> of the code.
>>>     any comments on this are very appreciated.
>>
>> We are in a similar situation, with an architecture in our
>> hands that needs software pipelining support. Since SW pipelining
>> is by its very nature quite architecture dependent, I don't know
>> how much could be generalized, but we would certainly be interested
>> in working on it.
> that's good news. in the past, we made good experiences with compiler
> components generated from a high-level architecture description, i.e.,

Are you referring to OpenIMPACT / Elcor? The pair are designed to be  
used in that manner. Their description languages can be used to  
describe low level HW details which TableGen isn't yet capable of.  
Nevertheless, LLVM is a production quality compiler while those are not.

> we already generated descriptions for a graph coloring register
> allocator,
> a scheduler with operation table support, and a grammar for a tree
> pattern
> matcher - though not yet for llvm but for a hand-crafted backend.
>
> so far, it appears to be reasonable to derive the architecture
> dependent portions from a target resource model specification, e.g.,
> using
> TableGen. however, we're at the very beginning of this project and
> i'm not
> yet aware of all the details. we'll definitely come back to you  
> once we
> have more insight.

If you interested in describing a in-order execution architecture  
where details such as port constraints, exact read / write latencies,  
you should expect to make some extensions to TableGen. The PPC  
backend comes closest to that, you should take a look to determine if  
you need more details than its processor itinerary class data.

If your target require full predication support and / or beyond basic  
block scheduling. There are some work required there as well.

Evan

>
>
> cheers
>
> -
> dietmar
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the llvm-dev mailing list