In D127495#3581809, @umesh.kalappa0 wrote:

@chmeee ,Can you commit for us ,since we don't have the commit access for the repo.

I'm not sure of the proper use of S31 in general, since ABI makes r31 the frame pointer in general. If we stick with only supporting the ABI, and not supporting alternatives, I think S31 should just be removed in general, unless we support omitting the frame pointer.

In D38778#1018576, @codeman.consulting wrote:

I have a couple of questions (along with a nitpicky inline comment).

The e500 docs from Freescale specify e500v1 which supports basically everything added except for the efd* instructions and the various vector insts; e500v2 is required for efd* inst. / double support. They also have different scheduling models. It looks you're just implementing e500v2, should this be specified at all, or is the e500v1 not needed as a target?

Is there a Clang portion to follow? To define builtins for all the intrinsics in C/C++. Or do you not plan to target SPE from C/C++?

In D41702#972009, @labath wrote:

In D41702#971076, @jhibbits wrote:

@emaste, @jhibbits: do you know what's the state of ppc64 lldb support in freebsd?

It's broken because LLDB doesn't yet handle function descriptors, and I haven't yet made the effort (ENOTIME) to fix that. I think our eventual goal is to move even BE to ELFv2 on FreeBSD, to do away with function descriptors, and it should then Just Work, as powerpc (32-bit) works fine for most cases right now.

That said, if anyone knows enough to add function descriptor knowledge to LLDB, I think that's the only missing piece, or the biggest missing piece. I do want to finish the effort, since I started it 3.5 years ago, but I do need help with understanding that ABI detail and how it fits with LLDB.

Thanks for the explanation. How badly is it broken would you say? Do you think that using this ABI plugin for the big endian target (instead of the one from 2014) would make things any worse? Could you take a quick look to see if there is anything in this plugin that would be completely wrong for the big endian target ? (I couldn't find anything, apart from the obvious things like register constants in CreateDefaultUnwindPlan, but then again, I don't know the ABIs).

I'm trying to avoid making bad design decisions now because of legacy code that is known to be broken and has no clear maintainer nor a plan to fix it.

Address most comments. I think tests are pretty complete now, and all bugs
found have been fixed. Removed selection for setcc on vectors.

Thanks for the review. It is in need of more tests, I know.

Correct e500 instruction scheduling.

Adding some more powerpc regulars in hopes of getting review. Feel free to remove yourself if you're not interested.

Add patterns for intrinsics for codegen, and fix the intrinsic definitions.

Add tests, add intrinsics (required for one test). Fix several bugs found via tests.

Tests are in the works right now. Until they're ready, this is a preliminary review, to see if I did anything unnecessary, or if I'm missing anything obvious.

LGTM