Re: Obsolete powerpc*-*-*spe*
On 21/02/2017 16:14, David Edelsohn wrote: On Mon, Feb 20, 2017 at 11:02 AM, Olivier Hainque wrote: On Feb 17, 2017, at 01:10 , David Edelsohn wrote: This is not a new issue. The maintainer did not suddenly resign last week. There have been numerous efforts to reach out to the SPE community for over a *decade*, cajoling them to step up with maintenance for the port. I am glad that this notice of obsolescence has focused more attention on the long-standing problem. Would there be a minimum level of commitment you'd like to get to accept leaving the port in (if not this, at least that ...) ? [...] There are three main areas that require attention: 1) Regular builds of the SPE configuration and regular GCC testsuite runs that are reported to the gcc-testsuite mailing list. 2) Timely reports of any regressions. 3) An active GCC developer who is the point of contact for the SPE port and submits patches for the port. None of us within IBM are experts on the SPE port. Someone from the SPE community is needed to help triage issues, debug problems and test patches that may affect the SPE port. With evidence of pro-active involvement from an SPE developer, the port does not have to be deprecated. The effort needs to be more that activity at GCC release cycle boundaries or an accelerated deprecation process will be proposed. I volunteer to be the point of contact for the SPE port. Over here at CodeSourcery/Mentor Embedded, we have a strong interest in SPE *not* being deprecated (we actively ship toolchain products with SPE multilibs, and have customers for which these are important). We are therefore volunteering resources (specifically, me) to maintain SPE upstream as well. I am in the process of developing some patches to add VLE support upstream (and expect to be maintainer of those once they are committed) so it would be a good fit for me to be the SPE maintainer as well. We have been regularly running tests on the SPE multilibs (on our internal branches) and they are in better shape than the test results Segher found from 2015. We may have some (not yet upstreamed) patches that improve the test results - I will be tracking these down and upstreaming them ASAP. I will be expanding our regular build and test runs to cover trunk as well, and will send test results to gcc-testsuite and report regressions. If there is no objection, I will submit patches tomorrow to un-obsolete SPE and add myself to the appropriate section of the MAINTAINERS file. The other changes will come once stage 1 opens. Thanks, Andrew
Re: Obsolete powerpc*-*-*spe*
On 15/03/2017 14:26, Segher Boessenkool wrote: I do not think VLE can get in, not in its current shape at least. That's unfortunate. Disregarding the SPE splitting plan for a moment, what do you think would need to be done to get it into shape? I had thought we were almost there with the patches that I sent to you and David off-list last year. > VLE is very unlike PowerPC in many ways so it comes at a very big cost to the port (maintenance and otherwise -- maintenance is what I care about most). I completely understand. Since SPE and VLE only share the part of the rs6000 port that doesn't change at all (except for a bug fix once or twice a year), and everything else needs special cases all over the place, it seems to me it would be best for everyone if we split the rs6000 port in two, one for SPE and VLE and one for the rest. Both ports could then be very significantly simplified. I am assuming SPE and VLE do not support AltiVec or 64-bit PowerPC, please correct me if that is incorrect. Also, is "normal" floating point supported at all? My understanding is that SPE is only present in the e500v1, e500v2 and e200z[3-7] cores, all of which are 32-bit only and do not have classic floating-point units. SPE and Altivec cannot coexist as they have some overlapping instruction encodings. The successor to e500v2 (e500mc) reinstated classic floating-point and got rid of SPE. Do you (AdaCore and Mentor) think splitting the port is a good idea? It wouldn't have been my preference, but I can understand the appeal of that plan for you. I'm surprised that the amount of shared code between SPE and PowerPC is as little as you say, but you have much more experience with the PowerPC port than I do, so I'll defer to your expertise on that matter. Are you proposing to take on the task of actually splitting it yourself? If so, that would make me a lot happier about it. >> -te200z0 >> -te200z3 >> -te200z4 > > These are VLE? Yes. > Do some of those also support PowerPC? All the e200 cores apart from e200z0 can execute 32-bit instructions as well as VLE, though we'll always generate VLE code when targetting them (otherwise they're fairly standard). Andrew
Re: Obsolete powerpc*-*-*spe*
Hi Segher, On 16/03/2017 19:24, Segher Boessenkool wrote: e500mc (like e5500, e6500) are just PowerPC (and they use the usual ABIs), so those should stay on the "rs6000 side". Agreed. Are you proposing to take on the task of actually splitting it yourself? If so, that would make me a lot happier about it. Yes, I can do the mechanics. But I cannot do most of the testing. That's fine (and what I expected). And this does not include any of the huge simplifications that can be done after the split: both ports will be very close to what we have now, immediately after the split. I'd have thought that the simplifications would be the bulk of the work... The simplification of the classic PowerPC port would be the removal of the SPE code. What would be removed from the SPE port - anything other than Altivec and 64-bit? All the e200 cores apart from e200z0 can execute 32-bit instructions as well as VLE, though we'll always generate VLE code when targetting them (otherwise they're fairly standard). Do any e200 support SPE, or classic FP? The e200z3 upwards have SPE units. None of them have classic FP. So it would make most sense for the e200/VLE support to be part of the SPE backend rather than the classic PowerPC backend. Andrew
Re: Obsolete powerpc*-*-*spe*
On 16/03/2017 21:11, Segher Boessenkool wrote: The e200z3 upwards have SPE units. None of them have classic FP. So it would make most sense for the e200/VLE support to be part of the SPE backend rather than the classic PowerPC backend. Great to hear! And all e300 are purely "classic"? That's one I'm less familiar with (as we don't deliver a multilib for it), but yes - my understanding is that this is classic core. Andrew
PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
On 13/03/2017 18:01, Andrew Jenner wrote: I volunteer to be the point of contact for the SPE port. Over here at CodeSourcery/Mentor Embedded, we have a strong interest in SPE *not* being deprecated (we actively ship toolchain products with SPE multilibs, and have customers for which these are important). We are therefore volunteering resources (specifically, me) to maintain SPE upstream as well. Ping. My understanding is that I need to be appointed by the steering committee to become a maintainer, but I have not yet heard anything from them. Either way, I will work on cleaning up the SPE test results and getting some patches sent upstream to make sure this part of the port is in good shape. Thanks, Andrew
Re: Andrew Jenner appointed PowerPC SPE maintainer
On 21/06/2017 16:40, David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has appointed Andrew Jenner as PowerPC SPE port maintainer. Please join me in congratulating Andrew on his new role. Andrew, please update your listing in the MAINTAINERS file. Happy hacking! Thanks, David! I've applied the following patch to update my listing in MAINTAINERS. Andrew * MAINTAINERS: Add myself as maintainer for PowerPC SPE port. Index: MAINTAINERS === --- MAINTAINERS (revision 249460) +++ MAINTAINERS (working copy) @@ -85,6 +85,7 @@ nios2 portChung-Lin Tang pdp11 port Paul Koning picochip port Daniel Towner +powerpcspe port Andrew Jenner riscv port Kito Cheng riscv port Palmer Dabbelt riscv port Andrew Waterman
Re: current state of gcc-ia16?
Hi Dennis, On 08/06/2018 11:37, Dennis Luehring wrote: is the patch already integrated into mainline? No, it's not. is this the most recent development place? https://github.com/tkchia/gcc-ia16 Yes, that's the right place. Andrew
Re: current state of gcc-ia16?
On 08/06/2018 12:43, Dennis Luehring wrote: is the patch already integrated into mainline? No, it's not. will that ever happen? Hard to say. There's no reason in principle why it couldn't happen, but there's not a big demand for it, so it would require someone taking the time and trouble to do it. It's not trivial, though - the current implementation has some middle-end changes which would need thinking through and doing properly to avoid polluting that code with ia16-isms. I might update it and have another try at upstreaming it at some point if nobody else does it first, but I have too much else going on at the moment so it would likely be a year or two (maybe more) before I get to it. Andrew
Reusing stack space for variables recorded during gimple lowering
I'm investigating the reason why the amount of stack used by some pieces
of code increased significantly since gcc 3.3. Notably,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505 has a testcase which
went up from 512 bytes to 20K between gcc 3.3 and 4.x, then back down to
~5K with later optimizations.
I've tracked down the remainder of the regression to variables recorded
during gimple lowering - these variables have a scope larger than they
really need to (the entire function), so don't share stack space with
each other or anything else. The two testcases attached (st1.c and
st2.c) should ideally use the same amount of stack but currently don't.
I've been playing with variations on the attached patch (which is
against gcc 4.1 but I think the mainline version will be very similar).
This does cause the compiler to generate the same assembly for st1.c as
for st2.c. However, it ICEs on this simple testcase:
int foo (void)
{
if (0)
{
return 0;
}
return 1;
}
This seems to be because in gimple-low.c, the BLOCK_SUBBLOCKS of the
DECL_INITIAL block is cleared and never reconstructed, due to new_block
and old_block being the same in lower_bind_expr. This leads to the
VAR_DECLs of the temporary variables not being seen during expand_used_vars.
I'm not quite sure what it is about the trees I'm generating that
gimple-low.c doesn't like.
Is there a way to make this patch work, or is this approach doomed for
some reason that I haven't understood?
Thanks,
Andrew
typedef struct
{
int a,b,c,d,e,f,g;
} L;
extern L bar();
extern L baz(L z);
void foo(int x)
{
baz(bar());
baz(bar());
}
typedef struct
{
int a,b,c,d,e,f,g;
} L;
extern L bar();
extern L baz(L z);
void foo(int x)
{
{
L t1 = bar();
baz(t1);
}
{
L t2 = bar();
baz(t2);
}
}
Index: gimplify.c
===
--- gimplify.c (revision 371010)
+++ gimplify.c (working copy)
@@ -61,6 +61,13 @@ static struct gimplify_ctx
bool into_ssa;
} *gimplify_ctxp;
+/* True if temporary variables should go in a BIND_EXPR associated with the
+ current statement. */
+bool use_statement_temps = false;
+
+/* If we are associating temporary variables with the statement, this will
+ hold them until the statement is finished. */
+tree statement_temps;
/* Formal (expression) temporary table handling: Multiple occurrences of
the same scalar expression are evaluated into the same temporary. */
@@ -596,7 +603,12 @@ gimple_add_tmp_var (tree tmp)
DECL_CONTEXT (tmp) = current_function_decl;
DECL_SEEN_IN_BIND_EXPR_P (tmp) = 1;
- if (gimplify_ctxp)
+ if (use_statement_temps)
+{
+ TREE_CHAIN (tmp) = statement_temps;
+ statement_temps = tmp;
+}
+ else if (gimplify_ctxp)
{
TREE_CHAIN (tmp) = gimplify_ctxp->temps;
gimplify_ctxp->temps = tmp;
@@ -4046,13 +4058,80 @@ gimplify_target_expr (tree *expr_p, tree
/* Gimplification of expression trees. */
+/* Given a gimplified statment *STMT_P, convert it to a STATEMENT_LIST
+ containing that statememtn. */
+
+void
+gimplify_convert_stmt_to_stmt_list (tree *stmt_p)
+{
+ if (!*stmt_p)
+*stmt_p = alloc_stmt_list ();
+ else if (TREE_CODE (*stmt_p) != STATEMENT_LIST)
+{
+ tree t = *stmt_p;
+ *stmt_p = alloc_stmt_list ();
+ append_to_statement_list (t, stmt_p);
+}
+}
+
+static void
+add_block_to_enclosing (tree block)
+{
+ tree enclosing;
+
+ for (enclosing = gimple_current_bind_expr ();
+ enclosing; enclosing = TREE_CHAIN (enclosing))
+if (BIND_EXPR_BLOCK (enclosing))
+ break;
+
+ enclosing = BIND_EXPR_BLOCK (enclosing);
+ BLOCK_SUBBLOCKS (enclosing) = chainon (BLOCK_SUBBLOCKS (enclosing), block);
+}
+
/* Gimplify an expression which appears at statement context; usually, this
means replacing it with a suitably gimple STATEMENT_LIST. */
void
gimplify_stmt (tree *stmt_p)
{
+ /* Save statement temporary information because we might be compiling a
+ statement inside another statement (i.e. in a statement expression). */
+ tree saved_statement_temps = statement_temps;
+ bool saved_use_statement_temps = use_statement_temps;
+ tree statement_block;
+ tree t;
+ tree block;
+
+ /* Clear STATEMENT_TEMPS so we know if any temporaries were created for this
+ statement. */
+ statement_temps = NULL_TREE;
+
+ /* Make sure that we are associating the temporaries with the statement. */
+ use_statement_temps = true;
+
+ /* Do the actual gimplification, which modifies STATEMENT_TEMPS as
+ necessary. */
gimplify_expr (stmt_p, NULL, NULL, is_gimple_stmt, fb_none);
+
+ /* If we have any STATEMENT_TEMPS, turn our statement into a BIND_EXPR
+ holding them and the statement that was gimplified. */
+ if (statement_temps != NULL_TREE)
+{
+ for (t = statement_temps; t ; t = TREE_CHAIN (t))
+ DECL_GIMPLE_FORMAL_TEMP_P (t) = 0;
+ gimplify_convert_stmt_to_stmt_list (stm
