On Fri, May 23, 2014 at 5:58 PM, Alessandro Di Federico
<[email protected]> wrote:
> Hi all guys, we are a group of research from the compiler group of
> Politecnico di Milano, Italy. We are currently working on a compiler
> for the OpenRISC architecture in the context of a project in
> collaboration with the University of Bologna and the ETH of Zurich.
>
> Basically we've been working to update existing LLVM backend for
> OpenRISC to the current official trunk and we have introduced several
> fixes and improvement, among which:
>
> * Refactoring of various parts of the backend (both TableGen and C++).
> * We implemented support for the missing instructions (l.m{f,t}spr,
>   l.addc, l.ext* and so on).
> * Major improvements in the integrated disassembler.
> * Some codegen improvements, in particular in instruction selection
>   and scheduling.
> * Fixed some bugs.
>
> Currently we're working on the selection of the MAC instruction in the
> IR, on the floating point and refactoring on the Clang driver and
> TargetInfo description.
>

That sounds great!

> We also have a proposal for a change to ABI in order to fix the
> inconsistency of the calling convention between ordinary and variadic
> functions. In particular, our proposal keeps unchanged the calling
> convention for ordinary functions. The parameter passing mechanisim is
> identical for both ordinary and variadic function, thus making the
> caller agnostic w.r.t. the callee kind (ordinary or variadic).
> Therefore we modified the va_list structure in order properly track
> parameters passed by register (that must be copied on the stack at the
> function entry) and parameters passed on the stack.
> Currently we implemented this ABI variant in our LLVM backend, and we'd
> be happy to have some feedback from you about it.
>

We've had a discussion about this last orconf, but it was decided to
keep the current ABI.

> We'd be excited to give a talk at ORCONF 2014 about this, if you find
> this of interest.
>

I'm sure there is, at least I'm interested in hearing more.

Stefan
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc

Reply via email to