LEON Sparc Sub-targets upgrade - first commit

[Chris.Dewhurst via llvm-commits]

> Hi James,
> 
> Thanks for responding.
> 
> The design was largely done before I started on the project and, while we expect changes to make the code acceptable to the LLVM community, I need to balance that need with the needs to avoid excessive churn in the LEON processor back-end design.
> 
> What follows is the briefest of explanations of the design of the LEON back-end. I've tried to structure them as questions so that you might be able to give me some feedback on what is most likely to be accepted by the LLVM community. I'd very much appreciate any feedback that you can give me and I'm very thankful for any amount of time you can give to this. I'm trying to keep this email as brief as possible to avoid taking too much of your time:
> 
> 1. The LEON back-end is implemented as a sub-target of the Sparc processor, based on the Sparc 32-bit processor. There are four variants: LEON2, LEON3, LEON4 and NGMP. Each is implemented as a separate sub-target. LEON processors support all Sparc 32 bit operations. Can I assume this is going to be the best way to implement LEON processor back-end support?
> 
> 2.  LEON additionally supports a few additional specialised operations, such as CASA, an atomic-cmp-swap instruction. I'm intending to add these as pattern matching features in  SparcInstrInfo.td, with appropriate constraints to target LEON-only. Can you verify that this is the best way to do this?
> 
> 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:
> 
> //LEON 2 FT (AT697)
> def : Processor<"leon2", LEONItineraries, [FeatureLeon2, FPUSupport, 
> SaveRestoreSupport, ReplaceSDIV, FixCALL, RestoreExecAddress, 
> IgnoreZeroFlag, FillDataCache, InsertNOPDoublePrecision, 
> RemovingRedundantLoads, LoopInvariantCodeMotion, 
> PromoteArgumentsToScalars, BasicBlockPlacement, 
> GlobalVariableOptimizer, CanonicalizeInductionVariables, 
> CanonicalizeInductionVariables, DeduceFunctionAttributes, 
> SimpleConstantPropagation, InternalizeGlobalSymbols, CodeSinking, 
> ReassociateExpressions, MemCpy, PromoteMemoryRegister, 
> LowerSwitchInsts, DeadStoreElimination, DeadGlobalElimination, 
> DeadTypeElimination, DeadCodeElimination, DeadInstructionElimination, 
> DeadArgumentElimination, DeadArgumentElimination, 
> GlobalValueNumbering, OptimizeCodeGeneration, MergeDuplicateGlobal, 
> DeleteDeadLoops, UnusedFunctionPrototypes, StripAllSymbols, 
> RemoveUnusedExceptionHandling, MergeFunctions, TailCallElimination, 
> TailRecursionElimination, LoopTiling, OptimizeExecutionTime, 
> OptimizeCodeSize, OptimizeDataSize, OptimizeSize, AllOptimizations]>;
> 
> Is this design going to be acceptable to the LLVM community? If not, what direction should we move in to implement hardware errata for these processors?
> 
> 4. Itineraries: Sparc currently does not implement itineraries. LEON processors, however, have multiple core support and itineraries are a required feature to optimise compiler output. As you can see from the definition above, LEON processors' definitions include itineraries (defined elsewhere, but not here, for brevity). Sparc processors will still implement no itinerary. This also requires a itinerary class to be defined for all existing instructions. e.g. FPU instructions largely have the same itinerary class, so FADDS would have this defined at the end as:
> 
> // Floating-point Add and Subtract Instructions, p. 146 def FADDS  : 
> F3_3<2, 0b110100, 0b001000001,
>                  (outs FPRegs:$rd), (ins FPRegs:$rs1, FPRegs:$rs2),
>                  "fadds $rs1, $rs2, $rd",
>                  [(set f32:$rd, (fadd f32:$rs1, f32:$rs2))], 
> IIC_fpu_instr>;
> 
> Is adding an itinerary to every Sparc instruction going to be an acceptable way to move forward with LEON implementation? I'm assuming that the lack of any itinerary on existing (i.e. non-LEON) processors means that these itinerary classes for the instructions are effectively ignored for any non-LEON processor.
> 
> Apologies for the length of email. I tried to keep it as targeted as possible and I think these are the biggest concerns I have regarding getting the code adopted by the LLVM community.
> 
> If you don't have time to look at or think about the whole email, any partial response will be much appreciated as it will help me to keep moving on any requisite implementation changes.
> 
> Best Regards,
> Chris Dewhurst
> LERO - The Irish Software Research Centre University of Limerick, 
> Ireland.
> 
> ________________________________________
> From: James Y Knight [jyknight at google.com]
> Sent: 27 August 2015 23:59
> To: Chris.Dewhurst; llvm-commits at lists.llvm.org
> Subject: Re: LEON Sparc Sub-targets upgrade - first commit
> 
> On Aug 27, 2015, at 2:58 AM, Chris.Dewhurst via llvm-commits <llvm-commits at lists.llvm.org> wrote:
>> The attached patch is an initial commit as part of a paid project I'm working on for the European Space Agency (ESA / ESTEC) to add LEON processor support to LLVM.
>> 
>> LEON processors are fault tolerant processors based on the Sparc V8 
>> processor line. The clearest way to implement this will be to 
>> implement it as a sub-target of the Sparc target. See the following 
>> for some details in overview: https://en.wikipedia.org/wiki/LEON
>> 
>> I have a large part of this code working, but as this is my first submittal to LLVM commits, I want to keep it small and hopefully uncontentious as the main purpose of this task is to familiarise myself with the LLVM committal process and develop my own list of incremental changes that will add to the LLVM system.
>> 
>> Please note that this is an ongoing project for me and the project is a full-time, paid position for which I will be able to continue to dedicate time. The project has a large, multinational sponsor in the European Space Agency. However, as a newcomer to open-source projects, please be gentle with me as I take this, my first, tentative step towards being an active developer on LLVM. I'm bound to make a mistake or two initially.
> 
> Welcome, it's always nice to see more people interested in Sparc! :)
> 
> I'd appreciate if you could please post your reviews to phabricator instead of just emailing them to the list, as it makes doing the reviews easier. See http://llvm.org/docs/Phabricator.html for more info on how to do this.
> 
> I'd like to just highlight one part of the instructions there which trips up almost everyone -- make extra SURE you add a mailing list as a subscriber to each review before sending it out. And if you fail to do so, it's best to just "abandon" the review and create a new one. As the docs say (but perhaps not prominently enough): "If your patch is for LLVM, add llvm-commits as a Subscriber; if your patch is for Clang, add cfe-commits."
> 
> I'd also recommend setting up the command-line "Arcanist" tool as mentioned in those docs, even though it's weirdly a PHP commandline application, as running "arc diff" is a *much* easier way to upload diffs than trying to do it via the webui.
> 
> Finally, as to your actual patch.
> 
> It's really a bit hard to review that in isolation without seeing more.
> 
> I'd have expected the first step here to be to add the new processor types (E.g. def: Proc<"leon4", ...>), not to add unused feature tags -- the features are basically internal, and aren't particularly useful to have until there's actually something that needs to depend on it.
> 
> I can guess that future patches might add some instruction defintions that use these features? But it's a lot nicer to review changes without having to *guess* what might come in the future.
> 
> Thanks!
> 
> James