- User Since
- Sep 8 2014, 1:26 PM (258 w, 3 d)
Mon, Jul 29
Should've marked it as need review earlier.
Jul 17 2019
Looks fine to me. Since it can be turned off, I don't see a problem if it causes issues.
Jul 16 2019
Jun 29 2019
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.
Jun 28 2019
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.
Jun 27 2019
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.
Jun 23 2019
Jun 16 2019
May 11 2019
Apr 29 2019
Apr 24 2019
Looks fine to me.
Apr 2 2019
Mar 28 2019
Mar 27 2019
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?
Mar 14 2019
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.
Mar 13 2019
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.
Feb 28 2019
Address feedback. Provide full context for diffs.
Address feedback. Provide full context for diffs.
Address feedback. Update patch to provide full context.
Feb 19 2019
I thought this would've been auto-marked as needs review when I updated, but apparently not.
Feb 5 2019
Incorporate patch from @kthomsen for handling globals.
Jan 29 2019
@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.
Jan 23 2019
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.
Jan 21 2019
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.
Jan 20 2019
One more argument index fixup.
Jan 18 2019
Hi Kei, thanks for that. I've updated my code, and will post an updated diff tomorrow.
Jan 17 2019
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.
Jan 14 2019
Fix expanding builtins to libcalls. Remove the need for intermediate illegal types in expanding and pairing the arguments and return values.
Dec 31 2018
Dec 29 2018
Nov 24 2018
Nov 15 2018
Nov 11 2018
Aug 14 2018
Yes, yes it is
Aug 10 2018
Jul 24 2018
Jul 17 2018
Jul 15 2018
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.
Apr 27 2018
@joerg ping on this? It's pretty straightforward, so should be an easy review.
Apr 22 2018
Rebase against newer head. Address several comments.
Apr 10 2018
Mar 23 2018
Mar 17 2018
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
Mar 12 2018
Mar 1 2018
Feb 26 2018
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.
Jan 18 2018
Looks fine to me. We should eventually add tests for this, for both endians.
Jan 9 2018
Jan 28 2017
Jan 25 2017
Oct 7 2015
Backtraces do work now, for ppc at least (ppc64 IIRC still has issues dealing with the function descriptors, but traversing the backchain does work). I can test this after I get my system set up from my move, but if you've tested it either natively or on a core then I'll greenlight it.