llvm dev - Feb 2007 - [LLVMdev] Software Pipelineing | Embedded C Extensions

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.,
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.


cheers

-
dietmar

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

hi,

On Thu, 15 Feb 2007, Evan Cheng wrote:
> 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.
no. i was speaking about a handcrafted backend developed at our lab
that basically replaces the rtl backend of gcc. however, it has never
been more than a prototype so far.
> 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.
thanks for the hint - we'll have a look at it.

-
dietmar