LEON Sparc Sub-targets upgrade - first commit

[James Y Knight via llvm-commits]

Sorry, maybe I misunderstood your earlier messages; I thought *you* had
inherited an existing code base you were giving snippets of and planning to
submit pieces of upstream!

Apologies if that was an incorrect understanding!
On Sep 8, 2015 4:36 AM, "Chris.Dewhurst" <Chris.Dewhurst at lero.ie> wrote:

> Hi,
>
> Thanks for all that useful information, although the one critical piece of
> information in here is about existing revisions, which I wasn't aware of.
> Moving forward from an existing code-base is almost certainly going to
> result in a higher chance of acceptance into the LLVM source code-base.
>
> I'm almost frantic in anticipation of finding out where this code is. I'll
> keep looking, but finding this is likely to dramatically alter my direction
> on this project. Any help appreciated.
>
> On the other notes, I had anticipated that the number of features would be
> viewed somewhat negatively - as I view them that way myself. The ESA
> requirement is that we can switch on and off individual features. However,
> Im fairly sure that getting the code accepted into the LLVM code-base has
> higher priority, so alterations to the design, even potentially to the
> project requirements are anticipated.
>
> Chris.
>
> 3. LEON's hardware implementation also has very many errata, which we need
> to fix as software optimsations. The intention in the design is to
> implement a back-end pass for each change and add these to the LEON
> target's information about the processor type. e.g. SDIV is not working
> correctly on LEON processors, but SDIVrr works correctly, so a back-end
> pass will modify the instructions to repair this erratum. A sample of a
> LEON processor type definition is as follows, with similar variants for
> LEON3,4 and NGMP:
>
>
> Yeah, these AT697 and UT699 processors sure have a whole lot of errata.
> [e.g. http://www.atmel.com/Images/doc4409.pdf is really rather
> astounding!]. Although, I'd note that most of them are already fixed by the
> AT697F and UT699E revisions.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150908/73339544/attachment.html>