Re: [avr-llvm-devel] Current Status?

[John M. <ato...@gm...>]

On Tue, Jan 3, 2012 at 8:05 PM, Sherard Dames <sc...@gm...> wrote:

> John,
>
> I've looked into writing more test cases. It seems that the LLVM
> regression testing system is incredibly easy to use, and I've already
> mocked up a few tests with it. Are there any specific things I should
> have in mind when writing tests?
>
> Borja would have a better idea of which tests are needed now. The MSP430
target (llvm/test/CodeGen/MSP430) may be helpful as an example. I think
we'll basically need tests for each asm instruction to start with. Also
test that show the avr-gcc ABI works properly (calls, returns, stack
pointer...). Also thinks like auto, global, static, and volatile variables.



> Will soon take a look at bringing the patches up to date with the LLVM
> trunk. (I assume we're talking about those in the
> svn /llvm/trunk/patches/)
>
> Yeah, and also the clang patches (cfe/trunk/patches).



> As for DragonEgg, not sure I understand it. From what basic research I
> did on it, I didn't find a whole lot of documentation but from what I
> gathered so far I'm not sure I see the benefits. The most obvious
> benefit I could see was to leverage GCC's existing AVR support instead
> of patching clang. However to me that just seems like shifting effort
> from one place to another (clang to DragonEgg) to get (essentially) the
> same result. That idea aside, as far as I'm aware, clang already tries
> to be very compatible with GCC. Additionally Windows does not seem to be
> on that list of "successfully used on" platforms for DragonEgg, and I
> might be wrong about this, but I thought Windows was the most common
> development platform for the AVR? What is it that I'm missing here?
>
> Basically it allows people to use the avr-gcc compiler and still get the
advantages of the llvm backend's code generation and optimization.
Personally I would prefer working on only Clang. I have a feeling though
we'll need DragonEgg to get people to transition over to CLANG/LLVM. I'm
more then happy to be wrong though.
There was (is?) an issue with windows dll's and the gcc plugin interface. I
read that there was a fix in the works though. Yeah, Clang is designed to
be a drop in replacement (minus a few purposeful exceptions) for gcc.