[llvm-dev] [RFC] AAP Backend

[Renato Golin via llvm-dev]

On 18 August 2016 at 13:31, Ed Jones <ed.jones at embecosm.com> wrote:
> Currently I am building a set of patches which will add AAP piece-wise.
> I'm following the approach that AVR (and now RISC-V), and the patches I
> plan on adding are as follows:

Sounds like a plan.


> At the moment there are only two changes to generic code, one is to
> override the size of pointers when printing assembly (for AAP we use
> larger pointer as the upper bits are used for flags), the other is to
> track live outs of a function (We have some registers which are callee
> saved, but also used for return values). I'm going to extract these
> changes into separate patches and submit them along with the above.

So, the discussion that has to happen before is: are those two
differences deal breakers for your target?

If the AAP back-end can't work without those two features, and they
prove hard to adapt, it may be hard to get the AAP in-tree.

But I don't think that will be the case. The CHERI back-end also has
fat pointers by default, and they were encouraged to merge their
changes, which is at least one similarity with your own back-end.

My personal take is that it would be good to allow non-integer
pointers in IR, but this may also prove complicated for the
middle-end. Time will tell.

Submitting those two patches, or at least their RFCs, would be a good
way to make sure there are no contentious issues with the rest of the
code.

Though, this should not stop you from putting up the actual patches
for review, and as soon as all the initial patches are approved on
their own merits, the target should be good to go.


> We're not planning on submitting the simulator yet, we have been keeping
> it outside of our main Target directory so that we don't write anything
> that unintentionally relies on the simulator or lets parts of it leak
> into any patches we submit. We may submit it separately at a later
> point, as part of the AAP target directory.

I don't think that's a good idea. The simulator should be a separate
project altogether, on its own GitHub repository, using the LLVM
libraries as such.


> I imagine either I or my colleague Simon Cook would be the code owner
> (or both if that's possible). The community is Embecosm, and those who
> may wish to use AAP as a basis for their work.

Should be fine.

cheers,
--renato