I made 8548 an alias in clang to e500, because e500 is recognized in llvm as a CPU, so gets us the feature list and, more importantly, the instruction scheduler.

Thanks for getting rid of SPE4RC, I really did not like it, but couldn't think of a better way. Glad you did.

Not in 9.0, but I will try to push for it in 9.0.1.

Thanks for pushing these through. They've been sitting in my private repo for too long now out of laziness.

Should've marked it as need review earlier.

Looks fine to me. Since it can be turned off, I don't see a problem if it causes issues.

Made '8548' CPU designation just a stub, to be filled out later. I added it
just for parity with GCC. The 8548 CPU, for GCC, also sets the
NO_LWSYNC macro, which doesn't belong with the SPE change, so will have
to be revisited later.

Actually, I'm not yet ready to commit this. I want to enforce the 8548 -> e500 processor model before I call this ready. How do I do that with the mcpu?

The immediate offsets for the evldd/evstdd instructions are UInt8, not SInt8, but otherwise your change looks fine. Do you have additional tests for it? You had mentioned before about problematic relocations, is that still the case with your patch?

I removed the extra spill changes. Those can be done later if there actually is a problem. This didn't change the tests at all. I'm not quite sure how to write a test to demonstrate that "some but not all" registers are spilled in a given case, given that the register allocator can change at any time, so can't hard-code the registers that would get spilled, and I don't think I can even hard-code the number of registers that could get spilled.

I'll commit it tonight. Was going to last night, but ran into a clang test failure, that turned out to be a long-standing failure with FreeBSD/powerpc64, not a problem with my change.

Reduce the scope of the patch.

Address nemanjai's feedback. Move the EVX check into a separate callable
function. In the future it could possibly be used as a separate addressing
mode, but a naive approach didn't work, and this solves the problem at hand.

Looks fine to me. @hfinkel or @nemanjai?

In D56703#1449235, @nemanjai wrote:

Can you add a test case? At least for the spills that you're adding.

Looks fine to me.

In D54583#1445579, @kthomsen wrote:

@jhibbits I don't know how to create a new revision here. My idea is to handle this fix via you, as you are already known for the SPE modifications.

Can you adjust the summary? This doesn't prevent floating point instructions completely, it only prevents floating point register constraints. The assertion that it prevents all floating point instructions is what I first took issue with, so please make it explicit that this is *only* regarding register constraints.

Reading through the diff again, closer, and checking the FreeBSD source, this is acceptable. FreeBSD only uses the base register, and hard-codes register numbers, so doesn't go through float register allocation.

Looks fine to me.

@kthomsen can you create a new revision just for that diff?

I'd like to amend my previous comment: FreeBSD, and I'd guess Linux, too, explicitly builds the kernel with -msoft-float, in order to prevent FPU-consuming optimizations. However, we still need to be able to save and restore FPU context, which requires inline asm (or a completely asm file, not something we want). This change would prevent us being able to do that.

I really don't like this. It should be possible to mix soft-float, Altivec, VSX, and SPE in the same file using inline asm. I put a check in for SPE codegen specifically to permit inline asm for other floating point models.

Address feedback. Provide full context for diffs.

Address feedback. Provide full context for diffs.

Address feedback. Update patch to provide full context.

I thought this would've been auto-marked as needs review when I updated, but apparently not.

Add feedback from @vit9696, and VAARG fix from @kthomsen.

Incorporate patch from @kthomsen for handling globals.

@vit9696 sure thing.

Hi Kei, that's fantastic! There's one more thing to add to this, which is to predefine NO_FPRS, and it should be a good replacement for gcc for 90+% of cases. I'll add your changes and this, and resubmit this review.

Hi @vit9696, it looks like Kei's patch fixes the issue you're seeing as well.

Hi Kei, thanks! I'll gladly add it to one of the patches. It might fit better with D54409, since the purpose of that is to fix the evldd handling in general.

Hi Kei, yes you need the patch in D54409, which fixes the offset handling. It should fix your case as well, but I didn't test foreign addresses.

One more argument index fixup.

Hi Kei, thanks for that. I've updated my code, and will post an updated diff tomorrow.

Fix argument indices for indexing through OutVals[]. It should be the argument index, not the physical register index.

Hi @vit9696, thanks for that, it was a straightforward fix. I'll post an update shortly for D54583, if arcanist cooperates. The short of it is I need two indices for arguments, since one is for logical arguments the other is for physical register allocation. I was only using 1, based on physical register allocation.

Hi @vit9696 it does crash with the linux target (powerpc-gnu-linux), but is fine with powerpc-gnu-freebsd.

This looks to be caused by using 128-bit long double on the platform. Does linux really use 128-bit long doubles on ppc32? FreeBSD uses 64-bit long double, so compiling that with '-target powerpc-gnu-freebsd' works fine. I'm not sure how to handle the 128-bit values.

Fix expanding builtins to libcalls. Remove the need for intermediate illegal types in expanding and pairing the arguments and return values.

Hi vit,

Hi Vit,

Hi Vit,

Yes, yes it is

Hi Vit,

Update diff to fix tests failing at this specific rev. All tests had previously
been run against D44830 instead.

Update diff to fix a test with the new register order.

@joerg ping on this? It's pretty straightforward, so should be an easy review.

Rebase against newer head. Address several comments.

Looks fine to me.

I will attempt to break this up into (slightly) smaller chunks. My current thought is:

• New instructions, and encoding tests
• e500 scheduling
• floating point and ABI
• intrinsics
• vector

I just did a search on NXP's website, and it appears the last e500v1-based chip went into production around 2001/2002, and had a Longevity-program lifetime of 10 years (MPC8560), superseded by rev 2.0 of the silicon, which used e500v2. So it appears there are no current e500v1-based SoCs in production at this time. e500v2-based SoCs appear to have another 8 years or so, as the latest one went into the longevity program in 2010, with a 15 year product lifetime.

Looks fine to me. We should eventually add tests for this, for both endians.

In D41702#971012, @labath wrote:

Hmm.. that complicates things a bit. How badly is it broken, do you estimate? Would it be any better than if we just made your new plugin handle the the big-endian target as well (just a best effort, I'm not asking you to actually test it on that target)?

If the ppc64be FreeBSD target is really broken, and there is no desire to fix it, maybe we should just delete the relevant plugin.

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